Your product exists to meet a true market need, and by doing so, to drive revenue. As such, it is a key component in the revenue engine — one of the main building blocks of the Mission / Strategy foundation layer.
Since your product is the central source of customer value, your product roadmap is an essential tool in optimizing revenue growth. Your roadmap prioritizes the projects you believe are the most critical to drive increases in value. It’s strategy in motion.
Product development is both resource-intensive and time-consuming. So it is important that you have a well thought through plan for how to expend your resources and time. The choices you make — of what to do now, what to do next, what to do much later, and what not to do at all — are pivotal.
It starts with your team. Do you have top talent in Product and Engineering? Your product development capacity will be gated by the competency of your team, especially your top execs. Make sure you have placed the very best into these positions.
It’s now widely understood that the agile development process is the optimal way to build software. You probably employ this approach. With it, requirements and solutions evolve through collaboration. Small cross-functional teams meet daily to review work. Development is modular, not monolithic. Early delivery is encouraged, with a continuous improvement mindset. Work is organized around monthly design sprints, and 1–4 week production sprints. By this method, you iteratively develop and rapidly release small increments of software at a time.
Decisions on infrastructure and architecture also impact development velocity. A microservices-based systems architecture is more responsive, resilient and elastic. Given today’s cloud-based systems with clusters running thousands of multi-core processors, with users requiring 100% uptime and immediate response times, and with the need to deal with big data, infrastructure and architecture decisions profoundly impact development velocity.
But agile development methods and micro-services based systems architecture are just enablers of great products. It all comes down to the product itself, and a great product must win in the marketplace.
As CEO, when it comes to product development you must maintain a delicate balance between discipline and flexibility. On the one hand, the market keeps changing, so emerging insights will impact development priorities. On the other hand, the product development machine works best when it works methodically. Jerking priorities around creates massive inefficiency and endangers quality. Striking that balance is an act of leadership judgment.
As CEO, do you frequently bring the latest product idea right to a software developer who can “just make it happen?” Does your VP Engineering regularly declare, “Only I know what the client needs?” Does your Sales VP push for the rapid completion of some shiny new feature “to make sure we hit the quarter?” These are signs of a poorly designed product development system. Poor design creates problems and drains valuable resources. For example, business and engineering teams become misaligned. Product quality suffers. Production slows. Responsiveness to the market declines.
Here is a quick quiz:
- Is your systems architecture monolithic?
- Given your requirements, do your product and engineering teams lack the skills necessary to execute your product plan with very high fidelity at every level of the stack?
- Are your teams too small given the development load?
- Do your product and engineering teams exhibit inefficiency in development?
- Do you fall short of the requirements for a true agile development process?
- Do you have a “shiny object” problem, whereby priorities are excessively re-juggled?
- Are your sales, marketing, product, and engineering teams misaligned on product vision and priorities?
If the answer to any of these question is yes, you have basic problems that must be addressed before you can address product roadmap optimization. Start by putting in place the right people, the right infrastructure and architecture, the right sized teams, a rationalized development process and a disciplined priority-setting approach.
Start small and scale carefully. It is better to execute well on a few critical priorities, than to execute poorly on everything.
Once you are sure your basic product development system is sound, you are ready to turn to the question of prioritization.
The first prioritization decision is to weight infrastructure work versus product work. As CEO, it’s important to support your VP Engineering in the allocation of resources to infrastructure projects. They are vital. They will yield scalability, reliability, and development velocity down the road, even though they will slow market-facing product development in the short term. Fight the instinct to starve these projects in favor of market-facing product work. That’s almost never a good decision.
With infrastructure projects built into the product roadmap, the remaining resources can be dedicated to market-facing product projects. Which ones do you work on first? Too often, these priorities are comprised of your case list submitted by current customers. The loudest complaints yield the highest prioritization.
This is a certifiably bad approach. The cases that fly in from highly engaged customers are necessary — but insufficient — contributors to prioritization decisions. As CEO, you should be at least equally concerned about the voiceless: the customers who exhibit little or no usage of your product, the prospects who considered but never bought, the prospects who like your features but value safety (i.e., are waiting on security features, enterprise reporting features, etc.), and the prospects and segments that “should see value” but won’t buy.
The smart process for product roadmap decision-making looks something like this:
Selecting the Problems to Tackle
The first step in making smart product roadmap decisions is to figure out your “true problems.” You might have a:
- Value problem — can’t efficiently acquire customers
- Velocity problem — customers like the product once they’ve bought and become familiar with it, but the conversion fall off (from initial interest to engagement to trial to purchase to familiarity and high satisfaction) is excessively steep
- Retention problem — can sell the product, but product limitations yield excessive churn
- Chasm crossing problem — can’t move beyond the innovators and early adopters within your top priority segments
- Segment expansion problem — can’t move from initial top priority segments to the adjacent high-opportunity segments
- Customer expansion problem — can’t get existing customers to increase purchases or expand use
True problems are not found in your office. They are found in the marketplace. In Chapter 4, Customer Segmentation, completion of an atomic-level “use case scenario exercise” was advocated. For each use case, you were asked to answer a series of questions. One question was to estimate in percentage terms the degree of product / market fit. Through research such as this, you clarify how prospects and customers within specific use case scenarios currently perceive your product’s value, and where the product falls short. By understanding these true problems at the segment and even use case level, and by ranking your segments by their importance to your future growth, you can determine what development initiatives matter most.
A “true problems” analysis might yield product development projects that:
- Alter or even pivot the product to address a value problem within existing top priority customer segments, so that initial sales increase
- Improve the onramp to your product to increase new customer adoption velocity for customers within existing top priority customer segments
- Improve retention by making changes to the product that address the reasons for churn
- Fortify the product to address the safety / dependability / reporting needs of early and late majority customers within existing top priority segments
- Build out the product to address the needs of new customer segments you seek to enter
- Build premium product extensions that allow you to offer premium packages for existing and new customers / segments
- Build new products to serve adjacent needs which you can sell to existing and new customers / segments
Let’s consider each type of “true problem.”
The Value Problem:
If the true problem is value (i.e., you can’t efficiently acquire customers because they don’t see the value), you have your work cut out for you. You must first validate whether it’s a messaging problem. If you have confirmed messaging is not the issue — in other words, prospects understand what you offer but they don’t want it — then you must conclude that your entire product thesis was wrong.
If you’re in this situation, you have no choice. You must go back to basics and validate:
- Within the customer segments you seek to serve, what exact problem are you trying to solve, down to the use case level?
- For each use case, do both buyer and user experience enough pain from the problem that they will pay you to solve it?
- What exact requirements must the solution address?
- What list of specific features is required to deliver on these requirements?
- Can you build it?
- How long will it take you to build it?
- How many resources will be required to build it?
- If you build it, are there enough ready-to-buy prospects to justify your investment and build a big business?
- Given what you’ve already built, is there an alternative problem you can solve that is faster to build, less resource intensive and / or opens you to a larger growth opportunity?
Since you did not adequately validate your assumptions the first time around, it’s important to do so now. You will face pressure (possibly even from your investors) to move quickly, but truth is much more important than speed. The marketplace, your prospects, and the competitors are all in motion. Finding the true, enduring pain that only you can solve takes work. Where do these needs and emerging trends within top priority segments intersect with your capabilities? This is the essence of product strategy. Talk to more prospects, not less. Make home or office visits; don’t just call. To the best of your ability, step into the lives of your prospects and customers and figure out exactly how this next iteration of your product will make their lives better.
The Velocity Problem:
If this is your problem, the customers who have purchased your product and have begun to use it properly are happy. The problem is that prospects initiating engagement with your product fall off too quickly. They don’t persist with the product and convert at a high enough rate to become buyers and engaged users. Velocity problems often exist with open source “freemium” products. Here, the issue lies in the “first mile” of the customer experience.
The first mile is the welcome and introduction tour, the onboarding experience, explanatory copy, and the empty states and default settings that greet the customer — i.e., the customer’s initial product experience.
If this is your challenge, Scott Belsky’s post, “Crafting the First Mile of Product”¹ is spot on. Belsky encourages you to assume that all prospects are lazy, vain, and selfish. They need to understand, within 15 seconds, “why am I here,” “what can I accomplish,” and “what do I do next.” They want to receive a benefit for their time very quickly. If the first mile experience can be designed in a way that allows the prospect to “do” something that delivers immediate utility and is ego-gratifying, that’s best. As Belsky puts it, “Do is better than Show is better than Explain.”
The initial user experience must be simple. The empty states, such as dashboards that do not yet show data, should be designed to deliver some value. The default settings, such as tabs, pre-populated fields, and templates should contribute to a seamless, confidence-building experience.
Belsky argues that the first mile experience should consume at least 30% of total development time in the development of your product. Critically, it should be built early in the development cycle, not at the very end.
The Retention Problem:
When you can sell to the customer but you can’t retain her, there is one piece of good news. At least you know that the value you claim to deliver resonates. In solving a retention problem, you must first figure out whether churn occurs due to your failure to deliver on the value you have claimed, whether the wrong customers are buying in the first place, or whether there is another supporting requirement that falls short.
For instance, you might claim a business benefit from your technology that the customer simply doesn’t experience. That could either be because your product is incapable of delivering the benefit, or because the customer didn’t use the product properly.
Alternatively, the product might deliver the promised benefit, but its purchase might come with an unanticipated collateral cost. Problems integrating a new product into legacy technology are often the culprit. More often than not, such problems result in organ rejection. Another source of churn can result from the effect of your product on customer employees. For instance, if your product displaces labor, the impacted employees could be instigators of churn by sabotaging successful implementation.
There are many possible reasons for churn. It’s on you and your team to figure out those reasons and to address them. You may even need to consider whether your choice of top priority segments must be revisited. Leverage data to see churn patterns. Talk to, and visit, enough customers to have high confidence you understand what creates churn. Only then will you be ready to develop new product solutions to attack the problems.
The Chasm Crossing Problem:
As Geoffrey Moore noted in his classic book, Crossing the Chasm², innovators and early adopters are different from early and late majority customers. The latter value safety over innovation. Not only do they require validation that your product has become the emerging standard, but they seek specific product features that reduce risk. For instance, mainstream B2B customers will require high levels of security and identity protection. They may require robust enterprise reporting features and may need the product to offer proof that it’s delivering its intended ROI.
The feature requirements of early and late majority customers can be gleaned by attempting to sell what you already offer. Interested mainstream customers will balk when they learn you don’t have this or that. It’s then incumbent upon you to develop a way to rigorously capture the “this” and the “that.” As you assemble the list of required features, you can further test your emerging chasm crossing thesis with more mainstream prospects until you have high confidence you understand what’s needed. At that point, you’re ready to build.
The Segment Expansion Problem:
Perhaps you have built a product that has been widely adopted by your top priority segment. Your success has been exciting but you can see on the horizon that your first segment will soon cap out. To continue your rocket ship growth rate, you must conquer new, adjacent segments.
When this is the true problem, it’s common for CEOs to make a key mistake. They overestimate the similarity of the existing segment to the next segment, opting to forego thorough analysis of the new segment’s unique use case scenarios and needs. The result is too often a “lipstick” makeover that does not fit the new segment’s true needs nor solve its true pain points.
Once again, the solution is clear but hard: deeply engage the buyers and users at the use case level. Gain a thorough understanding of the pain that must be solved and the requirements that must be met. Then involve prospective customers in your development process so that by the time you’re done you have built a product you know your next segment will buy.
The Customer Expansion Problem:
If your product enables customers to increase the quantity purchased, but your customers are not buying increased quantities at the rate you had expected, you have a customer expansion problem.
Start by figuring out the nature of the bottleneck. Alternatives include:
- Not satisfied with the quantity already purchased (churn risk)
- Have bought enough already; don’t need more
- Don’t know how to buy more
- Haven’t been encouraged / reminded to buy more
- Want to buy more, but facing some impediment (within or outside the product)
Since these are existing customers, the task to thoroughly understand the bottleneck should be relatively easy: just reach out to enough of them to gain pattern recognition and confirm your assumptions. Once you understand the bottleneck, you can design the product features that will overcome it.
Solving the Problems: Product Design
Once you have definitively prioritized the problems you will tackle, the real work begins. This work will consume product manager and engineering time, so it needs to get onto the product roadmap. Changing a product roadmap is like turning an ocean liner. It’s reasonable to expect that any shifts in priority will need to be made gradually so as not to disrupt existing projects midstream (unless, of course, it is determined that existing projects are off strategy).
True problems in hand, you are ready to design a product concept that will attack and solve them. Since development is costly, it’s key to validate your product concept with low-cost methods first.
The sequence of work should look something like this:
- Review competitor solutions; determine existing best practices (to achieve feature parity) and feature gaps
- Develop a solution thesis, with storyboards
- Test the thesis / storyboards with prospects and customers; iterate
- Build a light version of the product; test and iterate
- Build a beta version of the product; expand to a meaningful number of customers; test and iterate
- Full Release
Final thoughts
As CEO, your decisions in the product arena will profoundly impact your company’s viability and ultimate valuation. So it’s best not to screw it up. Start by making absolutely sure you have the right team in place. Build a modular systems architecture. Create a disciplined, agile development process. Think outside-in. Work hard to ascertain your true problem. Ensure top team alignment. Design and test every proposed solution, recognizing that the objective is to increase long-term customer value as measured by revenue and profit growth. Great products prove their worth via unit economics: high LTV and efficient CAC. Your product roadmap decisions are some of the most important decisions you’ll make. Do your homework, and choose well.
Epiphanies are hard won.
______________________
1. Scott Belsky, “Crafting the First Mile of Product,” published on Positive Slope, Medium.com, June 21, 2016
2. Geoffrey Moore, Crossing the Chasm (New York: Harpers Collins, Third Edition, 2014)
