A common incorrect assumption made about product strategy is that it’s exclusively intended for greenfield initiatives. Taking into account emerging and/or evolving markets, the ebb and flow of customer needs and wants, and more concrete elements like funding and timelines, that fallacy quickly falls apart.
That leaves a clear conclusion: Product strategy is valuable at any point in the product lifecycle.
Let’s assume that we have a product that’s existed for quite a few years now. We’ve spent a non-negligible amount of time and money building and maintaining this product, which has so far performed adequately, but now it’s time to think about serious growth. We’d like to start implementing data-validated product strategy initiatives to alter the trajectory of the product in a meaningful way, both for us and our customers.
There are three critical components that we’ll want to be aware of:
- Challenging the assumptions that have historically been held,
- Organizing key stakeholders, and
- Avoiding the sunk-cost fallacy.
Being aware of these components from the start will result in a more meaningful strategy engagement, even if we learn things we don’t want to hear.
1. Challenging Assumptions
There are two kinds of assumptions that we’ll need to be conscious of when thinking about our product: the ones we know we’re making and the ones we don’t.
The assumptions we know we’re making are quite easy to tackle. Reducing these biases starts with working backward to define how we got to these assumptions. Did we do some research? Do we have some institutional knowledge? Are these just our gut feelings?
Bucketing out each of our assumptions into these categories lets us know which are worth keeping around and which are ripe for the challenge.
Of course, the assumptions we don’t know we’re making can be much more dangerous. There isn’t a clear way to identify these from the outset, but once the product variables are designed and tested we can let the data speak for itself. Perhaps we’ll uncover heuristics we’ve thusfar held as requirements that can be downgraded as nice-to-haves or even slated for deprecation.
Let’s say we’ve now gotten as far as we can on identifying our known assumptions and we’re looking toward the next phase of challenges: clarifying our unknown assumptions. There are two main ways that we can test: user interviews and A/B testing.
User Interviews
User interviews are a great way to have dialogue-driven data on customer behavior and needs. The goal of a user interview is to gather qualitative data (and potentially anecdotal data) that can inform product evolution decisions.
The interviews can be paired with or without a testable prototype, depending on what you’re looking to learn.
A/B Testing
A/B testing is a great way to minimize confounding factors when testing specific product variables.
Consider building a low-fidelity prototype (as these garner more authentic feedback since the user doesn’t feel guilt responding negatively to a fully designed product) and testing either virtually with screen recordings, or in-person. Be sure to arrive to the test with a core user journey and identify points of contention that can mold themselves nicely into design sprints.
Challenging assumptions is a crucial part of the product strategy groundwork. And having these processes on hand can help in another important part of the process: organizing stakeholders.
2. Organizing Key Stakeholders
Coming back to our product, let’s think about how we got to where we are today. There was likely some great idea created by a few folks, funded by a few other folks, and built by another group of folks.
It’s typical that each person involved likely feels a sense of ownership of the product, and a great deal of pride in the success of it so far. Taking this into consideration, it becomes apparent that change can be difficult, since it will require alignment of each of these teams, alongside the alignment of the strategy team.
A product is lost without strong product ownership. Quickly identifying roles and responsibilities is the first step, and a great way to start is by using a RACI matrix. A RACI matrix defines who is Responsible, Accountable, Consulted, or Informed for custom-chosen subsections of the product, organized by vertical, project phase, or some other grouping.
Imagine that we have a leader on our team on the business side who has been assigned the role of Accountable for the vision of the product, but not the role of Responsible. Let’s also imagine that they are particularly inclined to a product vision that is not only in direct competition with previously learned user data, but also in opposition to the Responsible party. How can we handle this?
At this stage, it’s critical to account for the human element, and getting pushback from the powers that be is not a healthy place to be. Consider testing the hypothesis of our stakeholder with a low-budget, short-timeline user interview or A/B test, and analyze the results without biases.
If the results end up in favor of our stakeholder, then it’s wonderful that we’ve learned something new. If they don’t, that’s a difficult conversation to be had between the Responsible party and our Accountable party, but it’s made easier with unbiased data to support the final decision.
Lastly, for whole-team learning, consider launching a retrospective on the amalgamation of all previous product iterations. This doesn’t have to be anything formal, especially since it’s potentially larger than a traditional retrospective would account for, but try to set some structure to it. What went well? What didn’t? How can we use our learnings to close the gaps or enhance future wins?
3. Avoiding the Sunk Cost Fallacy
The sunk cost fallacy is, at its core, the belief that because we have invested so much in something that we should continue to invest in it. That investment can take the form of time, money, effort, headspace, or anything else. Avoiding the sunk cost fallacy with regard to product building is crucial to maintain market ownership.
Let’s say that through the testing we’ve done, we’ve found that our product has mediocre performance in a bloated market, but is not performing well in a market space that has tons more potential. This tells us that we have an opportunity to shift, hitting a new user base and answering a new user need in this new market opportunity.
It’s no secret that research and rapid prototyping cost time and money, but they don’t cost nearly as much as continuing to build the wrong product. Let’s imagine two scenarios for our product:
Scenario 1: Keep Going
In this scenario, we’ve decided to continue moving forward with the original product vision because we think testing and serious product strategy cost too much money and take too much time. What we’re going to do instead is build the feature that our Accountable leader wanted, and keep building upon that.
It will take three weeks to design this new feature, six weeks to develop it, and one week to run quality assurance and launch. We are now 10 weeks into building a product that is not based on data but instead on the feelings of a decision maker. Assuming that each person who worked on the project is paid $100 per hour, we are looking at a cost of $40,000 to build an untested product into a market that is already congested.
Scenario 2: Test and Iterate
In this scenario, we’ve decided that engaging product strategy is a critical component to be sure that we’re building the right product with an identified market fit. We’ve found a company that will help us bring in fresh ideas and a new set of eyes on the product. We’re going to engage their work for five weeks with the help of a product strategist and a design strategist.
It will take two days to customize and host a workshop to define the product blueprint and the driving factors behind it, three days to build generative research, three weeks to set testable hypotheses and low-fidelity prototypes to support them, and one week to analyze the findings and build a product roadmap rooted in qualitative and quantitative data.
Assuming that each person who worked on the project is paid $100 per hour, we are looking at a cost of $40,000 to not only have the answers for what should be built right now, but also to have a product roadmap with testable milestones in the future as well.
Both of these scenarios come out to the same amount of dollars, but one of them takes half the time and builds a much more reliable action plan for today and a vision for the future.
Being mindful of the benefits of product strategy can do wonders for the product evolution, reducing technical debt, and ensuring that the key players on the team are finding the work fulfilling and rewarding.
Conclusion
Taking the leap on product strategy, understanding that it may uncover unknown biases, shake up the decision-making dynamics in the workplace, and shine a light on wasted time and money, is a difficult but critically necessary thing to do.
Maya Angelou once said, “You can’t really know where you are going until you know where you have been”, so embrace the changes that are to come that couldn’t have been possible without learning from past decisions.
