An important part of the Product Owner responsibility includes envisioning the product evolution through the time, looking at the entire arc of the pre and post-production software life cycle.<\/p><\/blockquote><\/figure>\n<\/div><\/div>\n\n\n\n
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\u2019s the trend? What historical data can tell us for similar industries or technologies?\u00a0<\/p>\n\n\n\n
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\u2019t need in the next 6 months. Of course, the existing gap between best prediction and the reality shouldn\u2019t be an excuse to avoid the exercises of envisioning how end user needs will evolve, imagining opportunities, monitoring marketing trends, asking what\u2019s next, anticipating issues or improvements or wishes, yet assessing need for resources or new skills, updates and next versions’ roadmaps.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Let\u2019s 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.<\/p>\n\n\n\n
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”.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
As you don\u2019t need a technical background to be a good product owner with full understanding of the product, you also don\u2019t need a crystal ball to start thinking about the future of it.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"ngg_post_thumbnail":0,"footnotes":""},"categories":[263,325],"tags":[252,271,253],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p90hsv-9W","jetpack-related-posts":[{"id":609,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/10\/product-owners-dont-need-to-be-technical-to-be-good-part-2\/","url_meta":{"origin":616,"position":0},"title":"Product owners don’t need to be technical to be good – part 2","author":"Daniele Dav\u00ec","date":"October 28, 2020","format":false,"excerpt":"In part one, I wrote about the myth of existence and need of technical product owners. We left our hypothetical PO at a party answering few questions around his or her product. As we saw, the product owner needs to own the product knowledge base. If you are a PO\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":607,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/10\/product-owners-dont-need-to-be-technical-to-be-good\/","url_meta":{"origin":616,"position":1},"title":"Product owners don’t need to be technical to be good – part 1","author":"Daniele Dav\u00ec","date":"October 28, 2020","format":false,"excerpt":"Today I want to write about the product owner (PO) or product manager (PM) role and not to provide a definition or list responsibilities but address a specific myth. I am talking about the myth of the existence and the need of a technical PO.","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":555,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/07\/is-your-team-doing-scrum\/","url_meta":{"origin":616,"position":2},"title":"Is your team doing Scrum?","author":"Daniele Dav\u00ec","date":"July 26, 2020","format":false,"excerpt":"There many tools and checklists to verify wether your team is doing Scrum and how good (or or bad or ugly) is implementing it. If you are a Scrum Master, self-assessing the following statements from 1 (strongly disagree) to 5 (strongly agree) can help you to make a reality check\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":673,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/02\/spikes-102\/","url_meta":{"origin":616,"position":3},"title":"Spikes 102","author":"Daniele Dav\u00ec","date":"February 11, 2020","format":false,"excerpt":"In my previous article \"Spike 101\" I introduced the concept of Spike and it's general use in Agile. In that article we saw that: Spikes are investigation activities -e.g: research, design, investigation, exploration, prototyping- to gain the knowledge to solve a problem.\u00a0As Scrum doesn\u2019t prescribe any particular type for Backlog\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":791,"url":"https:\/\/www.danieledavi.com\/blog\/2021\/03\/changes-are-welcome\/","url_meta":{"origin":616,"position":4},"title":"Changes are Welcome","author":"Daniele Dav\u00ec","date":"March 10, 2021","format":false,"excerpt":"There are different levels of understanding\u00a0Agile.The first one is where you care about rules. You take every best practice, guide, book, training suggestion and you make a strict process out of context and without interpreting the reality. That's not Agile. That's you using Agile to cover your need of implementing\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":671,"url":"https:\/\/www.danieledavi.com\/blog\/2020\/02\/spikes-101\/","url_meta":{"origin":616,"position":5},"title":"Spikes 101","author":"Daniele Dav\u00ec","date":"February 10, 2020","format":false,"excerpt":"Scrum is often described as a very prescriptive framework despite this is not the case. Take for example the various type of backlog items that we are used to deal with in our favourite backlog visualisation tool. Some work with Epics and User Stories only, others use a mix of\u2026","rel":"","context":"In "Agile"","block_context":{"text":"Agile","link":"https:\/\/www.danieledavi.com\/blog\/category\/agile-2\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"amp_validity":null,"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts\/616"}],"collection":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/comments?post=616"}],"version-history":[{"count":5,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts\/616\/revisions"}],"predecessor-version":[{"id":643,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/posts\/616\/revisions\/643"}],"wp:attachment":[{"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/media?parent=616"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/categories?post=616"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.danieledavi.com\/blog\/wp-json\/wp\/v2\/tags?post=616"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}