A product owner’s guide to future planning

As a product owner, one of the main headaches you may experience is planning the future. The common pain points related to this process are:

• It’s easy to get swamped in the daily routine and lose focus on the long-term vision. The lack of time and the need to resolve ongoing issues make it almost impossible to pause and think about the future.
• The larger the team, and the longer the timeline, the more difficult the planning exercise becomes.
• Getting enough capacity to properly plan the upcoming 1/3/6+ months doesn’t look feasible in a  classic start-up environment.

Your planning process should be as efficient as possible for the above reasons. To achieve that, one should ensure the following:

1. One can devise a list of ideas for a future roadmap in a reasonable timeframe
2. Regardless of where the initiative came from, its implementation will yield the value

Preparing a list of initiatives:  

One may struggle once thinking about the question: What should I do next with my product? In which direction do we want to go? In this article, I will provide a simple structure by outlining and going through the main sources of inspiration for your roadmap. Also, I will describe some considerations one should pay attention to while working with each source:

Feature requests

Once managed properly, feature requests are one of the most useful, powerful and measurable sources of ideas for initiatives. The best thing about those is that all requested features have some addressable market.

A good example: your colleague from a large enterprise sales team has provided you with a feature request. This request comes from one of the top-3 players on the market, with annual revenues of $500 mln. The client says they are willing to start using your product as soon as your service sends push notifications to their users.

Let’s discuss the example above in more detail and understand why it’s good and what are the  criteria to which you should pay attention in real life:

– The market is measurable and large enough. Whenever you receive a request from some client,  the first question you should ask is what we as a company will get from doing so. Challenging and validating the potential impact is one of the main things one should remember while working on the feature requests.

– The requested feature is the only blocker to go live with this client. You should always align with sales or directly with a client to ensure that this future request will transform into a manageable cycle of new future requests, making it impossible to launch the product. One simple exercise to sense-check the proposal is to try receiving the answer to the following question: “Once we serve this request, what is the probability of winning that client”?

– Think about the future. Serving the specific client and covering their use case is nice. But did you think one step ahead to ensure your implementation is scalable and will cover other use cases from other potential clients? For instance, a client asked you to start sending specific emails on behalf of your service. What are the other possible use cases in this situation? What other pieces of data may you be asked to include in future emails?

Internal requests as part of overall company’s strategy

Internal requests can come from your line manager, other team or even the CEO. For instance, the company you work for introduced a loyalty program. During the upcoming quarter, every product team’s goal is to ensure that they introduce support for loyalty program.

Two main considerations for this type of source:

1. The positive side is that high-level and long-term direction has been defined for you, so you  don’t need to spend a lot of time thinking about the initiative from scratch but rather focus  on the implementation

2. However, one should remember that, most likely, the initiative has yet to be scoped in much detail. It is the job of the product owner to answer the following questions:

• How can this be applied to my product? Is it in line with our vision?
• What benefits will my customers get once we complete this initiative?
• What we as a company will reap once I deliver this initiative? Especially from the perspective of main KPIs you can be responsible for.

Technical and other debts

Everything that, at some point in time, will serve as a blocker for further development or will cause trouble will fall into this category. For instance, it can be a migration from monolith to microservices to ensure sustainable development in the future. Another example: your compliance team has revealed the gaps in your data-protection procedures. To cover yourself in the future, you want to make the changes as soon as possible to avoid penalties.

While considering this type of initiative, one should be reasonable and carefully assess the risk materiality and likelihood vs the effort required to mitigate.

Initiatives aimed at boosting key metrics

Assume the main KPI of your service is a conversion rate from sign-up to purchase. Most likely to achieve it, your service should offer as little friction as possible while sustaining sufficient motivation for users to proceed.

Now take a critical look at your product: are there areas of improvement? What do your event tracking data, A/B testing insights, or other information tell you? Try to apply the 80/20 approach and define which parts of the service you want to address first to achieve the best results.

Keeping pace with competitors

When Apple introduced the smartwatch, it created a new market.  Samsung had no choice but to start competing in this new market. However, one should not blindly follow the competitors each time they come up with something new. Keep in mind:

1. Does this feature makes sense and has a high addressable market? Or has my competitor made a bet on a niche market trying to test some hypothesis? Replicating a competitor in a  latter case is not the smartest option.
2. Can I compete in this field? Imagine you have a product portfolio that allows you to compete successfully with the largest organisations. For instance, you are providing a cheaper and better alternative to Microsoft Office. Imagine that you want to compete with Windows and spend the next two years developing your operating system. Are you confident in the success? Think twice before making such a decision.

To summarise, in this article I’ve outlined a simple structure and provided a description of the most common sources of inspiration, and one should consider them while planning the further development of their product. I would also mention that there’s no need to focus on one basis only – on the opposite, the more sources are considered, the better diversification can be achieved, increasing the chances of achieving success.