— — — — —
Have you reached a value breakthrough? Until you do, your existence is threatened. Once you have discovered that breakthrough, the world opens up. You earn the right to embark on the scaling path. Yet even then, the work has only just begun. Now you must extend and optimize that value. Now you must find a path to sustainable competitive advantage.
This is the innovation journey. It’s hard. Markets and customers evolve; competitors rise. Value has a half life. To keep ahead, you are challenged to build rising customer-defined value — day by day, brick by brick — while avoiding the waste of money and time in the process. But how? The only way is to first conceive of creative innovations, and then put them to the test to confirm their breakthrough impact. In this chapter, we focus on the first thing — conceiving of creative innovations. We’ll address the testing in later chapters.
The Product domain is made up of three subdomains:
- Product features
- Product dependencies
- Value proposition
All of these subdomains are important, but the most important of these is the Product Features subdomain. It is here that you solve your customers’ most gaping problems and meet their most screaming needs. It is here that you deliver transformative value. Only after you have discovered that value do the other two subdomains become important.
Product Claims — The Canvas
It is at the intersection of the Market and Product domains that customer-defined value happens. Of course, that value is monetized and captured via your Model, and it takes the right Team to make it all happen. That’s the Four-Way Fit. But value itself is found in the union of Market and Product. The framework (in both its canvas and spreadsheet forms) exists to help you crystalize the discovery of that Market / Product union. It helps you link up what you know about the Market with the solutions that become your Product.
The lean startup approach teaches us to test and iterate our way towards an initial product, and then to build it, measure customer impact and learn. All of this is good. But first we must conceive the fundamental pillars of value that will anchor the product. The power of these pillars depends on their capacity to overcome gaping problems and screaming needs. So before we engage in the detailed build / measure / learn cycle, we must first validate these pillars — these fundamental product claims.
Product Features Claims
Product feature concepts are easy to devise. What’s hard is to find a breakthrough product concept. It takes a talented team, fired up with passion to know the customer so deeply it can get the product right. Like an elite mountaineering party, it must hack a new path up and over three mountains.
The first is “Mount Simplistic”. As the journey begins, the way forward looks obvious. The path is easy and the climb is light. As the team makes it to the top, a bit out of breath, some mountaineers say, “Problem solved! Lets’ go home.” But others notice a second mountain, looming in the distance. It is “Mount Complex”.
The team marches down to go up again. The way forward grows steep. The path is soon riddled with hidden roots — previously undetected problems. Mountaineer after mountaineer trips and falls. Roots rise, turning into a dense thicket woven with intertwining use case scenarios and external dependencies. Vine by vine, the team must hack its way through.
Finally, tired and worn, our mountaineers stumble into an opening in the sky. “It’s the peak!” someone says. But no — it’s just a false peak. Many follow, until the exhausted team stumbles up over a rise, and there it is — the peak of complexity. What a bleak pace to be!
But there, off in the distance, is the final mountain: “Mount Simple”. Sheer cliffs rise towards the clouds. This mountain is the highest of all. As the team gathers its resolve and heads down to head up again, everyone realizes the path up this final mountain will be hard to find and hard to trek. Many previous teams, upon reaching this point, have declared victory and hiked home.
But our team of hardy mountaineers presses on, determined to find a path up the cliffs. Route after route proves a dead end; down they must go to try again. Eventually, after many failed attempts, the team finds its path. Up they go, hacking and rerouting and backtracking and up again, until ragged and worn, they stand in the rarefied air at the peak of Mount Simple. Joy is fleeting; soon a low rumble builds. In front of their eyes the mountain itself begins to rise, creating yet a new cliff to be scaled, a new peak to be reached. And so they come to the final understanding. Mount Simple never ends.
Phase I, the “discovery of a value breakthrough” phase, is made up of four stages: Immerse / Ideate, Minimum Viable Concept, Initial Product Release and Minimum Viable Product. At each stage, you must find the answer to a simple question: what is our winning product? It’s not easy to figure out. Absent customers, you are starved for data. Absent the ability to leverage statistics, you must leverage heuristics.
This phase is dominated by design thinking. If you are a design thinker, you will immerse and observe, learning via anthropological methods. As you live in the customer’s world, you will discern the contours of need. Within your sphere of interest, your chosen top priority segment will exhibit a purpose. Do you understand it clearly? To achieve that purpose, its personas (segment actors) will seek to accomplish a meta job. What, exactly, is it? In its pursuit, obstacles will impede progress. What makes it so hard to accomplish?
Real people encounter these obstacles. Who are the actors working to complete this job? Each has a unique persona. The obstacles cause these actors to struggle in completing the job and fulfilling the purpose. Because of these gaping problems, actors experience great frustration; the emotional effect rises until they feel a screaming need to overcome them.
Great products emerge from gaping problems and screaming needs. Solution ideation can help you crystalize these problems and needs. At first, you’ll be simplistic. Then you’ll be overcome by complexity. Eventually, with great effort, you will begin to discern solutions that you believe can be made customer-simple.
As fundamental solution ideas emerge, post them on the canvas. You don’t need to post the details — just the key product feature pillars. By doing so, you keep them visually adjacent to your Market claims. This visual adjacency is important — it’s a constant reminder that your product features claims must align with your segment claims. Do these features help segment actors complete the meta job radically better, faster and cheaper?
In this way, Market claims and Product claims teach each other. You gain an ever-deeper understanding of segment purpose. You better understand the meta job, and the obstacles actors encounter as they seek to accomplish it. This informs product ideation. As you concept-test your product ideas with visionary customers, their reactions help you to refine these product feature pillars — and even to refine your understanding of the segment itself.
Eventually, product feature concepts will turn into paper prototypes, which will become digital prototypes, which will become a single-feature concierge product, which will become an initial product release, which will become a minimum viable product. At any point along the way, you might discover that a fundamental product feature claim is flawed. While it’s always best to catch a mistake early, life doesn’t always work that way. When you do, return to the canvas. The act of doing so will cause you to ponder once again the linkage between Market and Product claims, and to ensure all claims on the canvas remain comprehensive, integrated and internally consistent.
And so it proceeds. From high-level understanding to a deeper, more detailed understanding you go. You break down the meta job into its supporting jobs to be done. You enter into a tighter, richer conception of product features. As you continue to concept-test these, your product vision clarifies.
All too many early-stage startup CEOs miss the boat. They fall into the swamp of confirmation bias. Having raised investor money based on a well articulated product vision, they flail around seeking to defend this vision at all costs — even in the face of contrary evidence. How short sighted! With the CEO’s death grip fixed on rigid product claims despite contrary facts, a flawed product becomes inevitable. Don’t do that. Have courage. Observe, learn and, when necessary, be ready to admit you were wrong. As Lao-tzu said, “the truth waits for eyes unclouded by longing.”
Product Dependencies Hypotheses
The second product subdomain is Product Dependencies. No technology product is completely free of dependencies. There are two types of dependencies: external and internal. These dependencies are important to understand — and, if possible, to mitigate. In the “discovery of a value breakthrough” phase, internal dependencies are not that important — it’s OK to build a non-scalable product; you can refactor it later once customer value is proven. But external dependencies, if they exist, can be vital right from the outset.
Examples of external dependencies include:
- A data dependency (for instance, an auto dealer pricing tool might depend on access to monthly auto manufacturer incentives data, sent from the manufacturers)
- A product feature dependency (for instance, many companies depend on Google’s location awareness capabilities to power its software)
- A money dependency (for instance, some FinTech companies offer loans or bind insurance policies within their product offerings — and to do so they depend on banks to finance the debt, or reinsurers to underwrite the policy risk)
- A workflow dependency (for instance, to work properly a sales productivity product may need to sit atop and integrate with the Salesforce CRM system)
- A channel dependency (for instance, a B2B insurance marketplace might depend on lead flow from the US Chamber of Commerce website, or from QuickBooks)
- A rights dependency (for instance, a music site might depend on producer approvals to play an artist’s music)
- A legal, regulatory or compliance dependency (for instance, FinTech lending company may meet to meet credit reserve thresholds established by law)
Any external party that controls access to a product-critical asset exerts power over you. So it is important to declare these dependencies. For each, you must identify how you will mitigate the risk of being limited, overcharged or compromised. A fundamental product dependency claim should address:
- A description of the dependency itself
- The exclusivity of the dependency — can you find alternatives?
- The cost of the dependency
- Potential mitigations of dependency risk
Of course, the fewer external dependencies you have the better. Every external dependency increases risk and reduces control. Once you surface these dependencies and state mitigation plans as hypotheses, you can verify them through research.
Value Proposition Claim
Your value proposition posits the essence of customer-defined value. It centers product and engineering teams as they work to optimize that value, and it guides messaging for marketing and sales. It also helps you to establish proper pricing, because it clarifies your product’s quantifiable value or, for some consumer products, its psychological benefit.
During the “discovery of a value breakthrough” phase, your value proposition claim is speculative. Since you have few customers in this phase, you don’t yet have much proof of value. Still, it’s important to define your value proposition. Doing so forces you adopt the customer’s point of view. That itself is valuable. Further, it is the basis of your sales pitch, which you need in order to sell. And you need to sell in order to prove you have reached and moved beyond the Minimum Viable Product stage — in other words, that you have achieved your value breakthrough. You will update the value proposition regularly as product features and your product proto-strategy iterate towards truth. Until then, consider it a “best guess”, to be regularly updated.
In constructing a value proposition, the first step is to identify your product’s “value attributes” — the benefits of your product that customers most highly value. This can be ascertained through customer interviews and surveys. For instance, if the gaping problem is a time inefficiency or lag in a workflow, a key value attribute might be “high speed”. Using your experienced intuition, you can create a list of hypothetical value attributes, which can then be tested and verified with visionary customers.
Once you are clear on the value attributes most significant to customers, and amongst these the ones for which you might be able to deliver the most compelling competitive advantage, you are ready to build out your value proposition claim. A value proposition has the following structure:
- For (customers in top priority segments)
- Who are dissatisfied with (current market alternatives)
- Our product is (description of the product category)
- That provides (compelling reason to buy)
- Unlike (the alternative)
- We deliver (key product features that deliver the top ranked value attributes)
If your product delivers an expected ROI to your customer, declare that ROI as a fundamental claim, to be posted on the canvas within the Value Proposition subdomain. Your ROI estimate will inform pricing. It is tested in the final stage of the “discovery of a value breakthrough” phase (the Minimum Viable Product stage) when you begin trying to sell the product to early adopters. Some consumer products deliver emotional, not financial benefits — for these, of course, ROI is not relevant.
Product Claims — The Spreadsheet
In the second phase of company-building, the “value optimization / sustainable advantage” phase, product claims become more detailed. The meta job is now broken down into supporting jobs to be done, which may vary by use case. If you are beyond the Minimum Viable Expansion phase, you may well offer more than one product. You may also have multiple customer acquisition channels, some of which might require supporting product features or exhibit external product dependencies.
This proliferation of segments, products and channels creates product complexity. Complexity can easily cause a disconnect between product development and customer reality. The purpose of the framework spreadsheet is to throw a lasso around that complexity — to help you maintain the connection between Market and Product.
The act of developing your spreadsheet architecture is itself helpful in wrestling complexity to the ground. In the Product Features subdomain, you’ll need to determine the taxonomy of your sheet. Will you organize it by product, by segment or by channel? If you are a marketplace business, will you first organize claims by “side of the market”? The same questions will arise when you turn to the Product Dependencies subdomain. For the Value Proposition subdomain, you will probably organize first by segment, and then by product.
Take the time to think it all through. The way you organize taxonomic rank within these subdomains is a key factor in mastering complexity. If you do this work well, it will elevate your own mental model of the business.
Product Features Claims
In a rising enterprise, it’s not uncommon to see a product roadmap that looks something like this:
There’s nothing wrong with such a road map. It lays out the high level sequential milestones that must be accomplished, both in terms of the direct customer experience (new features, improvements and “stickiness”) and the enabling integration and infrastructure work required to sustain platform performance.
However, if this is your only way of visualizing the product roadmap, it comes with a risk. In a rising enterprise it’s so easy for the product development engine to become a manufacturing plant — focused on software outputs. Each product development team focuses on its own product or product component. Each has its own road map. Someone at the top defines the sequence of product features, and the manufacturing plant churns away, rolling feature after feature off the production line.
It’s a trap. Don’t end up in it. Never forget: your mission is not software outputs. It is business outcomes. The effort to work inside the framework spreadsheet keeps your product tethered to market and customer, for every permutation. In each segment you seek to serve, for each persona, what is the job to be done? How does each supporting job contribute to the meta job, and ultimately to the segment’s purpose?
Remember that the reason your product has value is that it helps overcome gaping problems and screaming needs with some meta job, inside some market, within certain customer segments. These problems and needs exist overall, and at the segment level, and within each of the supporting jobs to be done — in a pyramid of ever-more-detailed abstraction, like this:
The job of your product features is to address these problems and needs, like this:
Only after you understand these customer-centric insights — once your product claims have been verified and have become settled assumptions — then you can draw them into the tools your product development teams use to manage product progression. In the image below, notice how jobs to be done (user activities) and their supporting tasks can be linked to epics and user stories:
Such a tool can be used to guide agile team sprints:
Within the framework spreadsheet, the specific architecture you create for the Product Features subdomain depends on your type of business. If you boast multiple products, you’ll need to address each separately in the spreadsheet. If a product varies (in its meta job or supporting jobs to be done) by segment or channel, you will need to address these variations. If you are a multi-sided market, you will need to express product features hypotheses for each side of the market. As a general rule, if you have multiple products, the top taxonomic rank should be “product”.
Since there are too many business type variations to document here, I hope to set you in the right direction by example. Let’s say yours is a marketplace business. Perhaps you feature a two-sided market. There is one overarching meta job for the marketplace, with a different meta job for each side of the market. One side’s objective is to sell, and the other side’s objective is to buy. Let’s assume that within each market side, multiple segments exist — each exhibiting segment-level meta job variations, and variations in its supporting jobs to be done. The resulting architecture of your Product Features subdomain within the Product tab of your framework spreadsheet might look something like this:
Notice that the taxonomic rank is as follows: Product > Market Side > Segment > Purpose > Meta Job > Problems and Needs > Product Strategy > Supporting Jobs to be Done > Themes > Epics. Within each segment, there is a segment meta job. Each segment meta job is accomplished via multiple supporting jobs to be done. Each job to be done is matched to a theme, and each theme is made up of epics. the sheet scrolls on to Market Side B, which follows the same taxonomic structure.
In the spreadsheet, list product features down to the level of “epic”. This ensures Market / Product claims alignment without becoming so detailed it slows things down. In agile product development, speed matters. A product-led growth company might run twenty or more A/B optimization tests a week, iterating on multiple story-level features. The velocity of your “build / measure / learn” cycle is key to building value. That’s why story-level hypotheses are too granular to enter into the spreadsheet. Of course, if a disproven story hypothesis also disproves its overarching epic, you will need to replace that epic in the spreadsheet.
Now a word to leaders of larger enterprises. A common disorder in the large enterprise is to launch new product extensions presuming too much about customer needs. It’s hard for enterprise executives to fully embrace the notion that every new product is almost like starting a new company. There’s a tendency to resist the need to immerse with visionary customers, ideate, devise minimum viable concepts, and push out a minimum viable product to confirm initial fit. But it’s vital. Most of your early hypotheses will prove incorrect. To be successful, new product extensions must emerge from the same build / measure / learn iterative cycle your first product went through, like this:
As you scale, your product dependency claims rise in significance. Now you need to consider:
- The degree of impact to the company if the dependency cannot be fulfilled
- The degree of pricing power the counter-party has (if relevant)
- The capacity of the counter-party to shut down an existing dependency relationship
Product dependencies can bite you at scale. In my own startup (Digital Air Strike) we had a data dependency to a key vendor. The data that the vendor provided was essential to our promised value. There was no alternative source for this data. Imagine our consternation when, at contract renewal time, this vendor presented us with a sharp price increase. Frustrated though we were, we had no choice but to cave and pay. When you know your key dependencies, you can begin to develop dependency mitigation plans.
There are also internal product dependencies. Chief among them is the state of your technical stack. Does your product sit atop a monolith? Or is its systems architecture cloud-based, built as microservices, so that the system is responsive, resilient, elastic and message driven? The latter ensures scalability, updatability and efficiency. If, on the other hand, your technology is built monolithically, your product will cost more to run, will be harder to update and will be harder to scale. A large enterprise with a monolith underfoot will face the difficult choice of accepting its limitations, resulting in an incapacity to evolve at the speed of competitors, or to refactor its technical stack into microservices — a digital transformation that might take years and cost millions.
Microservices architecture takes extra setup work, so it doesn’t make sense until your product has hit the Minimum Viable Traction phase. But once there, your engineering team should begin to refactor your mini-monolith into microservices. The earlier you begin this work, the faster you’ll get through it. Once they have made the shift, you will begin to benefit from the velocity that comes from a modern reactive microservices-based technical environment.
As you scale, your systems architecture will enable you to organize product and engineering resources into domain teams, which can then own business outcome objectives within their assigned domains. They’ll be able to self-organize around these objectives. They’ll be able to execute updates on their own (at the data layer, application layer, integration layer and infrastructure layer) without much coordination. The most successful technology companies — from Amazon to Google to Netflix to Spotify and many more — work this way. It results in velocity — a key source of sustainable competitive advantage.
By exposing these internal product dependencies and their mitigation plans as claims, you bring them into view as key considerations on the scaling path.
In the spreadsheet, the full list of consideration topics may look something like this:
Once you have achieved a value breakthrough and have moved into the value optimization and sustainable advantage phase, your value proposition begins to have real impact. That’s why at every stage of growth, you must update it and confirm it through research. It is a north star for product development, guides pricing, and grounds all messaging to prospects and customers. A value proposition statement and expected ROI should be developed for each customer segment. Like this:
Now that you are in the second phase of company-building, you can leverage more data. You can survey customers, asking them to force-rank value attributes. Data streaming in from the product itself will also help you identify the features customers value most. Your sales department will have good instincts as to which value attributes matter most, and for which of these are you most competitively advantaged.
Your value proposition is the basis for your competitive positioning statement. Your competitive positioning statement informs your brand identity architecture, which in turn provides the foundation that drives day-to-day messaging. It also guides pricing. It’s super important.
To get to your next value inflection point, you must create new value. Since your product is the primary repository of value, it’s important to get it right. Product Features claims link to claims in other subdomains, such as Customer Segments, Pricing and Customer Acquisition Method. Are these linkages sound? By working in the framework, you are forced to think through these linkages and confirm alignment.
That’s why it’s so important to state your assumptions. It enables you to sort out which of them can be considered true — settled assumptions — versus those that must first be tested and verified. It costs real money and time to build digital product features. Can you discover your mistakes before you build anything, during concept-testing or rapid prototyping? That’s the best. Can you discover them while your product is still minimum viable? That’s second-best. As the lean startup movement has taught us, small-batch, incremental product development is the better way to go. Since no bet is very big, the impact of a flawed hypothesis is contained. Find your mistakes as quickly as possible. That’s the key to everything.