What “product strategy” means during Product-Market Fit | Rangle.io

And some tools to help you capture product strategy during this phase

Popular economist and Harvard Business Review editor Theodore Levitt described the product-market fit phase of the product lifecycle as when “a new product is first brought to market, before there is a proved demand for it, and often before it has been fully proved out technically in all respects. Sales are low and creep along slowly.” His description still holds true in today’s digital age.

The Product-Market Fit phase is about developing a market for the product and building product awareness. In other words, product-market fit has not yet been realized but product development activities are actively in pursuit of this milestone. Depending on the company and type of product, there may be heavy capital investments in marketing or sales to reach out to potential customers. Product funding for this phase is typically from early-stage/seed investors or via a bootstrap funding strategy.

If you read our previous piece on why product strategy is critical throughout the product lifecycle, then you already know that the primary objectives of product strategy change as the product grows and matures. Specific to the Product-Market Fit phase…

The primary objectives of product strategy

Product strategy during this phase of the product lifecycle seeks to achieve three primary objectives:

1. Communicating why the new product’s value proposition addresses a pressing or unmet customer need in such a way that compels customers to exchange value for it, and drives increasing adoption (positioning for product-market fit and accelerating growth post-fit)
2. Deciding what must be prioritized for the first product iteration at launch / for the minimum viable product (MVP) to solve early adopter needs and generate organic traction (building for product-market fit)
3. A plan for how to test, measure, and iterate on the MVP with real customers (achieving product-market fit)

What do you need to look out for?

Anyone who has gone through the hard work of capturing and implementing product strategy knows it is an ongoing affair that takes a lot of focus, coordination, and difficult decisions. During this transitional period where the team’s focus moves through a gradient from small experiments to pilots to MVP-building, there is also the very important work of defining the initial iterations of the product vision, the strategic goals, the prioritization framework for initiatives, the product roadmap, and the key minimum success metrics.

This necessitates clear lines of communication between stakeholders and the product team, especially if the stakeholders are not involved in the day-to-day of the team during this phase. It also means decision-makers need to be comfortable with making hard decisions (including necessary pivots), and making informed leaps of faith when key assumption risks have been reduced as much as viably possible while significant unknowns may still exist.

Given all this, there are common patterns and anti-patterns that you should pay attention to when capturing and implementing product strategy at this lifecycle phase to know if your product team is moving in the right direction. Through our collective product management experience at Rangle, some of our key learnings include:

Patterns

• Stakeholders are receptive to, or ideally fully engaged in, defining specific success metrics for experiments and prototypes, and conditions / signals of when a pivot is necessary
• All stakeholders at the working level have a shared understanding of the desired outcomes of the prototypes and MVP
• All stakeholders at the working level demonstrate understanding of the importance of continued learning and remaining lean at this phase, such as assessing every feature idea or request by asking “What do we hope to learn about our users if we implement this over the existing backlog?”

Anti-Patterns

• Stakeholders employ rigid project management processes and/or traditional capital investment processes that force the product team to focus on feature development at the cost of measuring what works/continued learnings that may signal necessary pivots
• Stakeholders put pressure on the product team to deliver a MVP without demonstrating evidence of strong problem-solution fit during prototyping and early testing (e.g. betas)
• Product data collected, either during pre- or post-launch usage, is not meaningfully used to inform strategic decisions (e.g. potential pivots, prioritization shifts, pilot extensions, etc.)

How do you go about defining product strategy in this phase?

There are many tools and frameworks product teams can employ to define product strategy during this phase. Here are a few we’ve found a lot of success when defining product strategy with our clients:

If you’re interested in trying any of the below tools and frameworks with your teams, you can download one-pagers on our Product Strategy Tools page to help you get started.

Product Vision Canvas

The Product Vision Canvas is that tool that facilitates discussion to describe, visualize, and validate the product vision and major components of the product strategy. It helps teams be clear about their shared understanding and assumptions on the product’s purpose and expected value creation. It’s a great way to catch significant assumptions and misalignments early on, before product development work starts. This lets teams identify any additional work they need to do to move in the same direction and any key assumptions worth unpacking.

The canvas’ primary strength is its simplicity — it quickly captures the core ideas and assumptions necessary to test and develop a product idea. It’s best used when:

• The product vision is unclear, or
• A shared understanding and alignment on the product’s aspirations is lacking among stakeholders, or
• How the product will support the company’s vision and goals is unclear

However, it is not intended for:

• Detailing how the goals will be achieved
• Providing a broader business model view of the product strategy
• Brainstorming of problems, target customers, or value propositions
• Use with mature products

Teams will get the most out of the canvas if they’ve already conducted primary and secondary research on the addressable market sizes and trends, target customers segments, and any competitors and comparators, and also put together an initial business model for the new product idea.

It is helpful to also conduct empathy mapping activities prior to using the canvas, to allow the team to first synthesize the key learnings from the customer research and identify major customer pain points and needs. If the team feels that they have a strong understanding of and empathy for the target customer segments, or engagement time is a major constraint for stakeholders, then the empathy mapping activities should be completed after the canvas exercise to further validate the needs captured on the canvas.

As with any canvas tool, it’s also important to note that the Product Vision Canvas should be a living document that’s iterated on as more assumptions are worked through.

MoSCoW Prioritization Framework

The MoSCoW Prioritization Framework is a popular and lightweight choice for ordering work, especially during initial requirements gathering. It sorts initiatives and features into four priority categories. Its roots in traditional project management means it’s flexible enough to be used in any project-related context, including as an additional layer of prioritization during user story mapping.

A prioritization framework is essential to any product strategy because it aligns teams on the criteria for decision making and helps reduce the negative effects of opinion-driven priority discussions. When the product team needs to move fast and doesn’t have much user data to leverage yet (characteristic of the Product-Market Fit phase), a lightweight framework like MoSCoW allows the team to quickly decide what is critical to the current scope and what can be de-prioritized. Scope creep and lack of focus both will spell death for the product during the Product-Market Fit phase, so it’s important everyone involved (especially stakeholders) understand what is truly important to build at the moment.

The framework’s primary strength is its simplicity — stakeholders and product team members only need to think about assigning initiatives or features to four easily interpretable categories. It’s best used when:

• A lightweight and qualitative prioritization framework is needed to move things forward (often in a product’s early stages), and
• The work is time-boxed, and
• No previous framework exists, or data inputs for an objective one do not exist yet

However, it is not designed well for:

• Data-driven decision making
• Prioritization that requires more objectivity — its highly qualitative nature is prone to time-consuming debates of opinions (avoid this with prep work like alignment on objectives and team norms on settling disagreements)
• Use with mature products

Teams will get the most out of the framework when they’ve already established the product vision, strategic goals aligned to the vision, and initial product backlog or list of requirements (i.e. a shared understanding of what may need to be built to achieve the strategic goals). After completing the MoSCoW prioritization exercise of discussing and assigning initiatives or features into the four main categories, the team should continue further refinement of the priorities within the “Must Have” and “Should Have” categories at the very least.

Feature-Driven Roadmap

The Feature-Driven Roadmap is a common variant of the product roadmap that describes how a product is likely to grow through the lens of specific feature development. It typically maps features to timelines and groups them into swimlanes by specific categories. It is meant to align stakeholders on priorities and provide the product team visibility on its progress towards achieving major milestones and/or releases.

It has received a lot of flak lately, and for very good reasons. But there are still a few use cases when it is a useful product strategy tool. During the Product-Market Fit phase is one, where the team has achieved relatively strong confidence in the problem to solve with the product (from the previous Problem-Solution Fit phase) and requires a clear plan to drive the development and launch the product before the opportunity window fades. The product team typically is still closely interacting with customers to understand their feedback as well, which helps to ensure that the feature-driven roadmap doesn’t deviate too far from solving for the customer’s problem and risk becoming an irrelevant or outdated list of things to build.

This roadmap variant’s primary strength is its relative ease of translating down to release and sprint plans, compared to other roadmap variants. It’s best used when:

• There is strong confidence in the importance of the problem to be solved by the product, and
• The priority of the product team is to give customers new product value, or
• The product is younger and seeking product-market fit, and
• There is direct user feedback that drives the development

However, leaders need to be very mindful when using this roadmap variant because:

• It does not clearly communicate the rationale of the why of the work or of its order, or the work’s expected outcomes (this can lead to order taking or stakeholder debates on work value during product strategy meetings)
• It may encourage teams to become too output focused

Teams will get the most out of using this roadmap variant when there already is a strong shared understanding of the strategic goals aligned to the product vision, initiatives to achieve these goals, and a prioritization framework in place. The roadmap is only an intention of the product development plan though. So activities such as user story mapping are needed after putting together the initial roadmap, in order to break down the features into the deliverables pieces of the product backlog.

In the next article of our product strategy series, we’ll delve into the next phase of the product lifecycle: Product Scaling/Growth. This phase requires a shift in strategy to not only iteratively maintain product-market fit, but to also grow market share and broaden the team’s focus to make the product sustainably scalable. Stay tuned for more on what product strategy seeks to achieve in this next phase, and some tools and frameworks you can use to define your product strategy at that point.

Originally published at https://rangle.io on March 10, 2021.