The Four-Way Fit — Chapter 3: Product Claims (Part 1)

— — — — —

Have you reached a value breakthrough? Until you do, business survival is in doubt. 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 understand the customer’s gaping problems and screaming needs, then conceive of creative innovations to address them, and then put them to the test to confirm their breakthrough impact. In this chapter, we focus on how to discover and build products. We’ll address testing in later chapters.

The Product domain is made up of three subdomains:

• Product features
• Product dependencies
• Value proposition

Let’s explore the claims to be built inside these three subdomains — as expressed in Phase I within the canvas, and in Phase II within the spreadsheet.

Phase I — The Canvas

Customer-defined value happens at the intersection of the Market and Product domains. Of course, that value is monetized and captured via the Model, and it takes the right Team to make it all happen. That’s what the Four-Way Fit is. But value itself is found in the union of Market and Product.

The canvas exists to help you tighten market / product synergy. It helps you link up what you know about the Market with the solutions that become your Product. Of course, to build a great product is both art and science. The insights that lead to brilliant product breakthroughs often occur in bursts of creative inspiration. They are more likely to come to mind while walking on the beach or while lying in bed at three in the morning than while at work inside the canvas (or the spreadsheet). Nonetheless, the canvas brings structure to your thinking. It enables you to place your most fundamental product claims into their wider context — the integrated set of claims that will create a successful business. This domain is composed of three subdomains:

• Product features
• Product dependencies
• Value proposition

Product Features Claims

All three Product 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 value discovery do the other two subdomains become important.

In Phase I, your mission is to achieve a value breakthrough as proven by the creation of a minimum viable product customers are willing to purchase, retain and use. Discovery of a value breakthrough is hard-won. It emerges in four stages: Immerse and Ideate, Minimum Viable Concept, Initial Product Release and Minimum Viable Product.

At every stage, the canvas is helpful. It is the receptacle for your product feature claims. Whenever fundamental solution ideas emerge, you can post them on the canvas. You don’t need to post the details — just key product feature pillars. They’ll appear right next to your Market claims. This visual adjacency is important — it’s a constant reminder to keep them in alignment. Time and again, the question will be asked: do these proposed features help the personas in your top priority segment complete their jobs to be one radically better, faster and cheaper?

In this way, Market claims and Product claims teach each other. Through failure, iteration and discovery, you gain an ever-deeper understanding of segment purpose. You come to better understand the segment’s 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. By posting every update to the canvas, you retain a holistic view.

The leadership competency required to do this well is design thinking. Design thinking is outside-in; it emerges from living inside the customer’s world. Design thinkers go beyond the segment to look at individual companies, and even more, individual people. Design thinking is human-centric. It progresses through five steps:

• Empathize — immerse; tune into the user; identify problems and needs
• Define — state the user’s most gaping problems and screaming needs
• Ideate — challenge existing assumptions; create product ideas
• Prototype — draft up proposed solutions
• Test — try solutions out

At each of these steps, design thinkers involve the customer — in observation, research, or testing. If you are a design thinker, you learn via anthropological methods. The resulting insights help you to ascertain the most significant problems and needs, and to construct their solutions.

Let’s explore how the canvas helps you progress from Phase I to Phase II.

In the first stage, Immerse and Ideate, begin by choosing your top priority segment. Once you’ve clarified your segment of interest, you must find and recruit at least a couple of visionary customers willing to let you immerse within their worlds. These “alpha” visionary customers don’t pay you money — they simply open up their worlds to you. You will need this inside view: without it, you’d just be guessing. Through immersion, by leveraging design thinking and heuristic decision methods you can begin to seek out a segment purpose that interests you and is of consequence to your customers.

Segment purpose is advanced by the actors inside the segment — let’s refer to them as “personas.” These are the people tasked with completing some meta job that advances the segment’s purpose. What, exactly, is a meta job? It’s the high-level description of the tasks required to advance towards the purpose. As the meta job becomes clear, the people most central to getting it done will become clear. As you begin to identify and profile these key personas, you’ll notice that each must complete a unique set of supporting jobs; once all of these supporting jobs are completed, the meta job is completed. As discussed in the last chapter, these are important insights. They should show up on the framework canvas as Market claims — inside the “Segment” subdomain.

As your key personas seek to execute supporting jobs, what happens? You’ll soon find they face problems along the way. Keep an eye out for the most gaping problems — the ones key personas express a screaming need to solve. These are the important ones. Customers will pay money to solve problems, but if you can alleviate emotional pain, they will throw money at you. These “Gaping Problems and Screaming Needs” should find their way onto your canvas.

From the pile of gaping problems you have uncovered, you will then select just one — an important one you are most capable of solving first. As you push, prod and probe around the edges of this problem, solution ideas will spring to mind. Now take a deep breath. Before you go too far down the solution path, it’s important to concept-test your ideas. Ask your alpha visionary customers to help you with the weeding and filtering so you can get down to the most viable solution concepts. All of this happens in the Immerse and Ideate stage.

Once you sense you’re on to something, you are ready to move on to the Minimum Viable Concept stage. By this point, product feature claims and market claims will be in sync. Now it’s time to ponder the other domains and subdomains. Must important product dependencies be considered? How much might the customer be willing to pay for a solution to the identified problem?

Eventually you will build a comprehensive set that touches all four domains — Market, Product, Model and Team. This exercise will reveal interesting linkages. What talent do you need on the team to build out this product? How will the price impact your customer acquisition approach?

Iteration is your friend. Even though your first set of claims will soon prove to be wrong in many of its details, it’s a starting point — a first draft. As you go along, you may find that as you build out claims in the domains of Model and Team, new implications for the Product itself will come to mind.

Every claim needs to be concept-tested with alpha visionary customers and, ideally, other potential customers not as closely associated with your efforts. You will go back to the canvas whenever a fundamental claim proves flawed. The discipline of doing so will keep your vision holistic and grounded in reality.

As your minimum viable concept becomes conceptually validated, you earn the right to begin development of your initial product. This marks your entry into the Initial Product Release stage. Working with visionary customers, paper prototypes will give way to a single-feature digital prototype. Soon you will have devised a concierge single-feature product, with a digital skin and lots of manual work on the back end. You’ll keep iterating until you confirm that this first single-point solution is delivering real value for the alpha (non-paying) visionary customers testing it. Along the way, whenever you discover a flaw in a fundamental product feature claim you will need to go back to the canvas, to update it.

As your initial product is released to alpha customers, it might become clear that more features are needed. Your product as it stands doesn’t offer quite enough value. You’ll need to take the same approach with these new features, building towards the minimum feature set a beta visionary customer would pay for.

As you do this work, keep your canvas updates at a high level. There’s no need to update the canvas for every little thing. Just make sure that any flawed fundamental product feature claims are fixed on the canvas, and any new ones are added. This helps you keep one eye on the big picture while your other eye is in the details. Both are important.

The moment your basket of features meets this minimum “I’m willing to pay for it” threshold, you will be ready to find your first paying customers. I refer to your first paying customers as “beta” visionary customers. If possible, your first product will be a concierge product, with a digital face and lots of human effort in the background to deliver value. These first customers will receive the product at a discounted price, reflecting the fact that it’s still in early development.

Beta customers are sure to find many faults with the first features — but if these they stay and pay, then you’ve reached MVP status. As you find and fix faults, the product will keep evolving. Soon your concierge MVP product will make way for your first digital MVP.

Progress is never perfectly linear. In Phase I, there’s a “two steps forward, one step back” dynamic. Great products are simple, but simple is hard. To get to “simple” you must struggle through “simplistic” and then through “complex”. Philosopher Lao-tzu once said, “the truth waits for eyes unclouded by longing.” It is good guidance for founding teams. Too many early-stage startup CEOs are afraid of the truth. They build a well articulated product vision and sell it to investors, even though the reality falls short. Then they flail around seeking to defend that vision at all costs — even in the face of contrary evidence. How short sighted! Great CEOs have courage. They commit to the hard slog from simplistic, to complex, to simple. They observe, learn and admit when they’re wrong. And then they keep going.

Product Dependencies Claims

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 — even now, while still in Phase I. You will begin to do this work when you enter the Minimum Viable Concept stage.

In Phase I, 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, are important to identify and even address right from the outset — because they will impact your fundability. Investors will look into the future; they will need to gain confidence no external dependencies will pose a significant risk to growth or profitability.

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 their products)
• 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, a sales productivity product may need to sit atop and integrate with the Salesforce CRM system to work properly)
• A channel dependency (for instance, a B2B insurance marketplace might depend on lead flow from QuickBooks)
• A rights dependency (for instance, a music site might depend on producer approvals so it can play an artist’s music)
• A legal, regulatory or compliance dependency (for instance, a FinTech lending company may need to meet credit reserve thresholds established by law)

Any external party that controls a point of dependency exerts power over you. Declare these dependencies within the canvas. 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.

In the Minimum Viable Concept stage, your value proposition claim is speculative. Since you have not yet launched your product and you have no paying customers, you don’t yet have much proof of value. Still, it’s important to define your value proposition. Doing so keeps you centered on the customer’s point of view. That itself is valuable. Further, it is the basis of your sales pitch, which you will need in order to sell.

You will update the value proposition once you complete the Initial Product Release stage and experience initial beta visionary customer reactions. You will refine it further as you trek through the Minimum Viable Product stage and your customer understanding deepens. By the time you exit the MVP stage (and exit Phase I), your value proposition should be fairly tight. Until then, consider it a “best guess”, to be regularly updated.

To construct 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 in your chosen top priority segment 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 you can then test and verify with visionary customers.

Once you are clear on the most important value attributes, 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 and post it 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.

Phase II— The Spreadsheet

In Phase II, the “value optimization / sustainable advantage” phase, product claims become more detailed. Now you move from one top-priority segment to multiple segments. You may have expanded into new verticals, or new regions, or new use case scenarios. As a result, your segments of interest may grow significantly.

Each segment has a purpose. The meta job that advances the purpose varies by segment. each meta job in each segment is achieved by people (personas) executing supporting jobs to be done, which may vary by use case. If you have passed the Minimum Viable Expansion stage, you may now 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. The purpose of the framework spreadsheet is to throw a lasso around this complexity — so that you can keep the connection between Market and Product, align these claims with claims in all other domains and, most importantly, build new value.

Your spreadsheet architecture is key to wrestling this complexity to the ground. You’ll first need to determine the taxonomy of your sheet. In the Product Features domain, will your taxonomy be ranked by product, by segment or by channel? If you are a marketplace business, will you first organize product claims by “side of the market”? You probably should. 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 the complexity. If you do this work well, it will elevate your own mental model of the business.

Product Features Claims

Your product has value because it helps key personas overcome gaping problems and screaming needs as they complete jobs. If these supporting jobs become easier to complete, then that will advance completion of the meta job. Such improvements occur within a certain customer segment, inside a market. As you expand to new segments you will encounter new use case scenarios — such as variations in the supporting jobs to be done. Like this:

Given the rise of new segments and use case scenarios, complexity rises. This increases risk of misalignment and confusion. To counteract that risk, it becomes important to organize the product under a unified product strategy, broken into epics and themes, like this:

When you take this approach to product taxonomy, it becomes easier to organize product development teams. You can take a domain-based approach, assigning product teams to different segments or themes. This is especially true if you have built your technical environment following reactive principles leveraging microservices architecture. If you have, then it is technically feasible for such teams to own responsibility for all four technical layers (the data layer, application layer, integration layer and infrastructure layer). This creates ownership and can increase customer focus, like this:

At enterprise scale, you might boast five, ten or fifty or more of these product teams. But even though these teams own business objectives within their assigned boundaries, complexity still exists in terms of cross-team integration. How do you keep these teams strategically aligned while giving them tactical autonomy? The framework spreadsheet helps.

The specific spreadsheet architecture you create for the Product Features subdomain will depend on your type of business. If you boast multiple products, you’ll need to address each separately. 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 yours is a multi-sided market, you will need to express product features claims for each side of the market. As a general rule, if you have multiple products, the top taxonomic rank inside the Product Features subdomain should be “the product” (product #1, product #2, etc.).

Since there are too many business type variations to document here, I’ll point 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 purpose, advanced by a 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, you can list product features claims down to the level of “epic”. This is about the right level of abstraction to ensure alignment with other subdomains.

Take care not to get too detailed in the spreadsheet — it will bog you down. In agile product development, speed matters. A product-led growth company might run ten 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. User story-level hypotheses are way too granular to show up in the spreadsheet. Keep the spreadsheet at the epic level. Of course, if a disproven user story hypothesis also disproves an epic, you will need to replace that epic in the spreadsheet.

Great products almost never flow from a rigid strategy-to-theme-to-epic-to-use case waterfall. On the contrary, as lean startup advocates would argue, great products tend to emerge the other way around, bottoms up — from use case to epic to theme to strategy. You start with a conception of the strategy, but it’s really just a proto-strategy. Strategy only emerges after the customer has proven its soundness.

This bottoms-up sequence repeats every time you build and launch a new product. It’s wise to remember that each new product brings you back to the beginning. The rising enterprise seeking to build a new product must first immerse and ideate, then develop a minimum viable concept, then release an initial product, then iterate towards a minimum viable product. This is the Phase I journey, revisited. It works something like this:

In the graphic above, you’ll note that under the Phase II stages of Minimum Viable Expansion, Minimum Viable IPO Path and Hot Public Company, Phase I also appears (the three boxes titled “Discovery”). That’s a reminder to approach new product initiatives as if they were new startups, with a separate team charged with traversing methodically through the four Phase I stages.

In Part Three of this book, you will see how this journey plays out through the stories of companies such as Zoom, Airbnb, Canva, Deputy, Airtable, DispatchTrack, Zuora, FiveStars and others. The path towards greatness follows a remarkably consistent pattern.

As you conceive of the product features claims that will populate your spreadsheet, don’t just consider functional product features. The features that help users get to these functional features are equally important. There are two types of these: the prospect experience and the customer experience.

Prospects often first encounter your product by landing on your home page. They are filled with impatience and doubt. Your mission is to get them, quick as a rabbit, to vision lock: “I get what you do and why it’s relevant for me.” When a prospect lands on your company home page, what happens? Do you instantly draw her into your product? Is there a mechanism for that prospect to enter real data and instantly receive some sample of real value? Failing that, can you create a freemium experience?

Companies that offer a sleek “first mile” prospect experience are called “sales ready” products. Sales ready products emerge from product development teams steeped in a culture of product-led growth (PLG), committed to the discipline of rapid product testing and iteration. Such teams might execute ten or more tests a week, continuously seeking to optimize the prospect journey. Such products offer a powerful competitive advantage. The product features that speed up a prospect’s discovery of value are important, and should be included in your spreadsheet.

Of course, the customer user experience is even more critical. That’s why every product development team working on the user experience should have on it a UX designer. For every user step, is this the fastest way to value? Is the user’s next step clear? Has every unnecessary step been eliminated? Be sure your product features claims address usability.

As you scale, the demand for new product features will constantly be greater than your capacity to build them. And as you scale, the platform itself will need to be refactored into a microservices architecture. This effort requires significant engineering resources. Within every product development team, and overall in high-level product strategy, tough choices must constantly be made. Which product features will be tagged in your spreadsheet as prioritized for development?

The RICE method is an effective approach to product feature prioritization. A RICE score takes into account four factors:

• Reach (the number of customers impacted)
• Impact (the degree of customer impact)
• Confidence (how confident the team is that our estimates are accurate)
• Effort (the cost in time and money)

The formula works like this:

(Reach X Impact X Confidence) / Effort = RICE Score

Such an approach brings objectivity to the prioritization and sequencing process.

Product Dependencies Claims

As you scale, your product dependency claims will 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 hurt you at scale. That’s why it’s so important to name them. It reminds you to develop mitigation plans. 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 other 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.

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 your 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 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 entered Phase II. But once there, your engineering team should begin to refactor your mini-monolith into microservices. 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. The earlier you begin this work, the faster you’ll get through it. Once you’ve made the shift, you will begin to benefit from that velocity.

By exposing internal product dependencies and their mitigation plans as claims, you bring them into view as key considerations on the scaling path.

In the spreadsheet within the Product Dependencies domain, the full list of consideration topics may look something like this:

Value Proposition Claim

Once you have achieved a value breakthrough and have moved into the value optimization and sustainable advantage phase, your value proposition will clarify. That’s important because it’s high impact: it affects your brand identity, all detailed messaging, the product road map and pricing. That’s why at every stage of growth, you must update it and confirm it through research. A unique value proposition statement and expected ROI should be developed for each customer segment. Like this:

Now that you are in Phase II, data plays a rising role in firming up the value proposition. You can survey customers, asking them to force-rank value attributes. Data streaming in from the product itself will also help you identify the attributes customers value most. Your sales department will have good instincts not just for the attributes themselves, but also for which of them deliver you the greatest competitive advantage.

Also in Phase II, your expansion into multiple products, regions, verticals and segments will prompt the need for multiple value propositions, corresponding to each permutation.

Your value proposition is the basis for your competitive positioning statements. Your competitive positioning statements inform your brand identity architecture, which in turn provides the foundation that drives day-to-day messaging. It also guides pricing. It’s super important.

Summary

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 canvas in Phase I and spreadsheet in Phase II, 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 too big, the impact of a flawed hypothesis is contained. Find your mistakes as quickly as possible. That is key.