Envision, imagine, anticipate the future of your product

Today, I would like to write about another important set of attitudes and abilities that a good product owner (PO) should possess.

As mentioned in the article I previously posted, PO doesn’t need to be technical to deepen his or her view and understanding of the role. Having a wider visibility and taking ownership on the various aspects, components, layers, corners, attributes and qualities of the product requires the ability to engage proactively with all stakeholders, make some questions, and surface high-level conceptual answers.

How does the minimum viable product (MVP) look like 1 minute after being released? What about after 1 day or 1 week or 1 month? Is post-production cycle and maintenance clear and defined? Have bugs been triaged and solved? Improvements deployed? What’s the life of the product in 3 months? How does the end user feedback enter in the production cycle or in the backlog? How does the release notes of the preview version look like? What features will be in the roadmap for the beta 6 months after the first release? Will the product survive and still be there after 2 years? Would it be just a pilot, an MVP, an experiment or a teaser? Has it been entirely substituted by then? Is it obsolete? Would by then competitors have similar or better products? What’s the trend? What historical data can tell us for similar industries or technologies? 

Of course, no one knows for sure what will happen tomorrow, in six months or in two years. Of course, no one should create waste filling up the backlog for something you wouldn’t need in the next 6 months. Of course, the existing gap between best prediction and the reality shouldn’t be an excuse to avoid the exercises of envisioning how end user needs will evolve, imagining opportunities, monitoring marketing trends, asking what’s next, anticipating issues or improvements or wishes, yet assessing need for resources or new skills, updates and next versions’ roadmaps.

We often ask development teams to provide estimations. Although we know they cannot predict the future and we know that probably they will keep receiving request for changes few minutes before a release and after. Even if we know estimations are educated guesses -sometimes not even meaningful- we should fairly expect from product owners and product managers to be able to do the same type of exercise.

Let’s also make clear that not everything is unknown-unknown or known-unknown. There are plenty of characteristics, qualities, practices, requirements, and issues known and very well known. Rejecting the need of looking for them will just multiple delays even around predictable activities.

It must be said that very few PO imagine the safe end or controlled dismissal of their product. What happens to users data? Who notifies the customers? Is there any impact on other systems or services? Is there any legal aspect to address? Of course is not a priority. Of course we have now several examples and case studies to look at, before saying “no one knows”.

Early engagements of all stakeholders in participating in similar envisioning exercise will help gather feedback, anticipate needs, stay ahead of requirements, foresee issues and tackle them per time, release before or more often or more comfortably.

Whether you want to anticipate a release date or not, it is better to have a choice than being obliged to negotiate delays, asking overtime, deteriorate work/life balance, mining psychological safety, increasing burnout risk, decreasing performance and overall satisfaction.

As you don’t need a technical background to be a good product owner with full understanding of the product, you also don’t need a crystal ball to start thinking about the future of it.