Do you remember the last time you had a conversation about a newly popular product that seemed to have started losing its way? Maybe it was a new snack that tasted a little different as its ingredients adapted to mass production requirements, or a once-niche home improvement tool that now seemed “off” in quality once it started marketing to the broader DIY crowd.
While that feeling of “off” is not always as immediately noticeable among digital products as compared to physical ones, there are countless stories and case studies of digital products losing their way during their Product Scaling/Growth phase. Mobile game developer Zygna’s much publicized downturn in 2013 has been attributed to some overly aggressive growth steps, including capital-heavy acquisitions and over-reliance on Facebook to grow their user base. Tink Labs, which initially found great success and had a post-money valuation of over US$1 billion in its growth phase, found their business model didn’t scale very well when they expanded into new geographies, and alongside internal scaling-related issues this led to a restructuring and eventual shutting of its doors. Even when Snapchat really became a popular social media platform in 2013, it was already plagued by continuous complaints of offering its Android users a sub-par experience that continued to drag on user perceptions until they finally addressed it in 2019.
While having a strong product strategic focus for their product’s Scaling/Growth phase may not have prevented these companies (and many others like them) from experiencing some major bumps in their product’s growth journey, it certainly would have reduced the likelihood of drastically negative outcomes. But before jumping into what product strategy looks like during the Product Scaling/Growth phase of the product lifecycle, it’s worthwhile to first review the phase’s characteristics.
How do you know if your product resides in Product Scaling/Growth?
In this phase, the product has found product-market fit and is accepted and sought out by customers, so the main focus of most companies has shifted to increasing the product’s market share. Marketing efforts transition to being aimed at a broader audience, communicating expanded value propositions to address the new target customer segment(s).
The focus of product development expands to include more emphasis on scaling, so that development, maintenance, and other operations can continue to support the growing demand and usage of the product. The increasing sales will often attract more market entrants and perceptions of direct competition threat, which typically leads companies to begin racing to release new product features. Some companies may also look to increase external investments to accelerate growth plans, but ideally they are at or near self-sustainment through increased sales revenue and/or improved unit economics.
With so many new considerations for stakeholders to manage during this phase, defining a clearly articulated and adaptable product strategy is of critical importance. If you haven’t read our previous piece on why product strategy is critical throughout the product lifecycle, we’d recommend giving that a read as well to understand how the primary objectives of product strategy change as the product grows and matures. Digging deeper within the context of Product Scaling/Growth:
The primary objectives of product strategy
There are four primary objectives that product strategy seeks to achieve during this phase of the product lifecycle:
- Align product scaling goals and initiatives to the company’s growth objectives (e.g. new market penetration, new revenue growth, cost reductions, etc.) and to increase market share
- Define the plan to transform the functional, technical, and operational aspects of the product to enable efficient scaling of resources to meet the growing user demand
- Balance continuous improvement and new feature development to solve for the needs of existing and new target customer segments
- Evolve the planning and prioritization processes and methodologies to become more objective, repeatable/predictable, and outcome-driven
What do you need to look out for?
With the ever increasing scope of work and more varied requests that define this phase of a product’s life, executing on product strategy necessitates strong coordination and clear lines of communication more so than in other phases. Relative to the other lifecycle phases, the product is most susceptible to losing focus during this phase. The overarching mandate to grow market share at this phase, while improving the scalability of the product, can lead to common pitfalls, including:
- Diluting or weakening of the product’s core value propositions
- Losing sight of strategic goals
- Becoming all-consumed by firefighting
- Fragmenting the product experience over geographies or device ecosystems
- The team feels they are jumping between disparate priorities with each sprint.
The product teams and stakeholders also face an increased variety of decisions to be made, such as deciding if it is more financially or operationally beneficial to use third party tools/solutions, or make acquisitions of other products, than to build out features or functionality in-house.
We’ve been very fortunate at Rangle to develop deep expertise to help our clients solve problems during this phase of their digital products. So we’ve learned that there are common patterns and anti-patterns that you should pay attention to when capturing and implementing product strategy during Product Scaling/Growth, to know if your product teams are moving in the right direction:
Patterns
- Stakeholders and the product team are always centered on the end-to-end user experience during scaling efforts (e.g. taking a full-stack development approach even if scaling efforts are primarily backend focused)
- Stakeholders take a targeted approach to automation of delivery, where they weigh the cost of automation development and maintenance against the potential value gain and effort savings; not everything needs to or should be automated
- Stakeholders and product teams consistently use an agreed upon decision-making framework when faced with important decisions, especially during emotionally-charged scenarios (e.g. build-or-buy decisions)
Anti-Patterns
- Stakeholders increasingly make decisions to accelerate growth over other priorities, pushing the product teams to leverage the success from launch to grow in all directions, or in an unfocused manner
- Stakeholders and/or the product team are hyper-focused on a specific feature set defined by a user cohort that does not properly represent the customer segments needed to increase market share
- Engineering efforts are increasingly siloed as product teams are directed to focus more on single features over maintaining coordination across teams, leading to decreased awareness of their individual impacts on the whole product
How do you define product strategy in this phase?
There are many tools and frameworks product teams can employ to define product strategy during this phase—enough to need a whole playbook to capture. Here are a few we’ve found successful when defining product strategy with our clients during the Product Scaling/Growth phase:
Value vs. Effort Prioritization Framework
A common prioritization framework using a 2x2 matrix, designed for teams to assess and compare each work item’s expected value delivered and expected effort required. It’s applicable to any type of work intended to deliver business or customer value, ranging from a team’s product backlog or roadmap, to an enterprise’s strategic initiatives, to a startup’s experiment backlog. Common variations of the framework that are functionally the same are called Value vs. Cost, Impact vs. Cost, Value vs. Complexity, Impact vs. Complexity, and Impact vs. Effort.
It can be used in a very lean fashion, or with the rigor commonly found in ROI-type analysis. Using it as a lean prioritization framework often involves stakeholders and/or the product team qualitatively plotting initiatives or features on the 2x2 matrix, with discussions focused on the rationale for each work item’s position relative to the others.
If more rigor is desired, a scorecard technique is used, where the “value” and “effort” factors are both composed of sub-factors that are agreed upon by the team. Layering on confidence multipliers to account for the estimations is a common variation, more closely resembling the ICE Prioritization Framework.
The value and effort sub-factors chosen by the team should be those most relevant to the product’s context. This can take some trial and error. In the early phases of a product’s lifecycle, scoring is often subjective due to a lack of data. But as the product matures and more data becomes available, teams should leverage data inputs for more objective scoring, automating intake and/or calculations where possible. Examples of data input sources include sales data, feature-specific CSAT score, historical operational costs, historical effort sizing, etc.
If teams want to apply even more rigor, the scorecard technique is layered onto the matrix (where the scorecard’s list is plotted onto the matrix using the individual value and effort scores), allowing the team to better visualize the scoring’s recommended order and make intentional priority adjustments.
The Value vs. Effort Prioritization Framework in more detail with an example of how the scorecard and matrix techniques are combined
This framework’s primary strengths are its simplicity and adaptability—it can be used for both new and existing products, and be adapted to the context of any market or industry. It can also evolve as the product matures, transitioning from mainly subjective to increasingly objective inputs. It's best used when:
- No previous prioritization framework exists, or the existing one lacks consistency and rigor
or
- Stakeholders and/or teams currently prioritize work in highly biased ways (e.g. HiPPO, equity/buy a feature, etc.)
or
- The team wants a scalable prioritization framework
However, some key things teams should be aware of:
- There can be high coordination costs when used with large products managed by multiple teams
- When inputs are subjective, it may lead to opinion-based debates
- When inputs are objective, it’s very easy for teams to counter-productively sink too much time into perfecting the scorecard
Teams will get the most out of the framework when they've already established the product vision, the strategic goals aligned to the vision, key success metrics, and the list of initiatives or features. While the output of this framework is usually a prioritized backlog or roadmap, it’s important to note that the power of any prioritization framework is to provide direction on the order of the work, not to serve as a prioritization bible.
If you're interested in using this framework with your team, download our one-pager to get started.
Outcome-Driven Roadmap
The Outcome-driven Roadmap is a common variant of the product roadmap that describes how a product is likely to grow through the lens of achieving the desired outcomes of customers and the business. It typically maps prioritized desired outcomes to broad timescales (usually quarterly or bi-annually) or to more priority-focused horizons (e.g. “Now, Next, Later”) without the traditional timescale that can cause viewers to become overly deadline-focused.
Some teams may choose to show the work at an epic-level on the roadmap, while others leave the solutioning out of the roadmap; Regardless of the approach, there is usually some grouping into parent strategic themes or initiatives. Additional info such as product team ownership or alignment to business goals or OKRs (Objectives and Key Results) are often made explicit, too.
It is ultimately meant to communicate intent of the product development, align stakeholders on priorities, and provide the team visibility on their progress towards overarching goals.
An example of an Outcome-Driven Roadmap for an industry online community product
There are very good reasons this roadmap variant has received increasing attention over the last few years, especially being compared against the Feature-Driven Roadmap. It reduces the risks of product development work becoming:
- misaligned or scattered
- ineffective or irrelevant in delivering meaningful customer benefits
- disconnected from company strategy
We too have observed product teams across industries and company size begin to be more deliberate about transforming outcome-driven product mindsets, with the Outcome-Driven Roadmap being a key enabler. While we won’t attempt to convince you of why you should use this roadmap with your teams (a lot already exists in the product thought leadership space—some of our favourite reads are here and here), we’d like to share some of our key learnings when using it so that you have a easier time employing it with your teams.
This roadmap variant's primary strength is its communication of product direction through the desired outcomes the product is intended to achieve—it makes explicit the “why” behind the development efforts, and keeps customer and business outcomes top of mind for all team members. It's best used when:
- Stakeholders recognize that focusing on creating solutions or meeting hard deadlines are not the most meaningful ways to measure progress
or
- The product team has strong confidence in the value of the desired outcomes the product should achieve
or
- The product is more mature and product development is experiment-driven
However, leaders need to be aware that to get the most out of this roadmap variant:
- Stakeholders and teams must have a strong experimentation mindset and culture to enable feature development (which also requires a solid analytics function)
- Supplemental project management artifacts may need to be created to provide stakeholders who demand regular forecasts or projected timelines
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, the goals’ key success metrics, the business objectives, and the prioritization framework. The roadmap is only an intention of the product development plan, though. So proceeding activities such as experiment design and user story mapping are needed in order to build up the backlog of work needed to achieve the desired outcomes.
If you're interested in using this roadmap variant with your team, download our one-pager to get started.
In the next article of our product strategy series, we'll delve into the first phase of the product lifecycle: Problem-Solution Fit. This phase requires a very different product strategy because the product team will only have unvalidated solution ideas, and so must prioritize achieving empathy for potential customers and a deep understanding of their problems. Stay tuned for more on what product strategy looks like in the early days of a product, and some tools and frameworks you can use to define your product strategy in that phase.