Thanks for sharing your question, Simbella. In your case, I recommend starting with populating the bottom sections of the Product Vision Board. Clearly describe who the users of the app are, why they employ it, and which business benefits it generates. Do this exercise together with the stakeholders. Then ask yourselves if the strategy you have captured is the right one to move forward with or if you should change it. Hope this helps.
]]>I just learned about the Product Vision Board, and am starting to read and watch as much information as I can find on it. How would you use this when the stakeholders are not clear on whether they need a product vision for a legacy application that still sits on a server? They are still thinking about technology requirements but they have stated they want a transformation. Is this the right tool for that? Are there other tools you can recommend?
]]>Thanks for sharing your question Valeria. The business goals section encourages you to state desired business benefits the product should create. These include generating revenue, entering a new market and diversifying the business, reducing cost, and increasing brand equity. Which goals are relevant depends on the product: a revenue-generating offering typically has different goals compared to an internal, supporting one like a software platform.
Once you’ve determined the right business goals, you may want to quantify them and state, for example, how much revenue the product is expected to create in the first two years of its launch. If that’s not possible, then don’t worry: If you follow my model, you’ll break down the business goals into smaller, more specific outcomes on your product roadmap. Hope this helps!
]]>You’re welcome Suzanne. As the person in charge of the product, I recommend exploring how you can directly connect with prospective users and customers/buyers. Receiving information from other groups like procurement is great. But to empathise with the beneficiaries of your product and deeply understand their needs, you need to directly reach out to them, as I discuss in the article 5 Tips for Building Empathy with Users. Good luck with the product vision board and your strategizing work!
]]>Hi Roman, Thank you for your reply. You have clarified which is great. By stakeholders I actually meant potential B2B buyers in the market not internal stakeholders. Very hard in our market to involve B2B potential buyers as we are actually trying to sell to them in a very competitive space, often with procurement depts involved. Thank you for the power interest grid reference though.
]]>Thanks for sharing your question Suzanne. If the users and customers are separate groups, then I recommend describing them separately in the target group section of the product vision board. Take a medical device like an X-ray machine. Its users are the radiologists but its customers or buyers are likely to be hospital trusts. Consequently, you would create two separate entries in the target group section, one for the radiologists and another one for the hospital trusts. You can indicate which group takes priority by moving it to the top of the section. As a rule of thumb, I like to give priority to the users. Here is why: A product is unlikely to achieve sustained success if it does not do a great job for the people who work with it.
Stakeholders, however, are not captured on the board. Instead, perform a stakeholder analysis using, for example, the power-interest grid, involve the key stakeholders aka players in important product decisions, and ask them to join the product team. Hope this helps!
]]>Thanks for your question Paris. Failure in the context of the article means finding out the one or more statements on the product vision board are wrong and possibly, that the strategy chosen will not work. As I write in the article, “figuring out quickly what works and what doesn’t, which assumptions hold true, and which don’t.” It’s important to accept that the initial product strategy might be wrong and not to cling to our preconceived ideas. Otherwise, we are in danger of building a product that nobody wants and needs. Hope this helps.
]]>You mention don’t be afraid to fail. Can you tell me what constitutes as failure here during the early stages of defining the problem?
]]>