Solutions and priorities: gentle introduction to this multi-part series (non-technical) on describing the essential elements of taking your product to market successfully.
In my previous post, I addressed the following: vision, decompose, user, and journey map. In this post, I will unpack solutions and priorities.
In product management, a moonshot solution might be creating an innovative new feature or service that satisfies a critical user demand. Alternatively, developing an altogether new method of distributing products may be necessary. Making a convincing argument for why any proposed moonshot idea is essential would necessitate rigorous problem-solving.
A moonshot solution, in general, is any significant effort that has the potential to transform an industry or change how people’s needs at met. Product management may use this term to refer to ambitious product development goals, such as expanding market share by 10x and establishing a new product category, among others. Overall, it is crucial not to overcomplicate solutions; instead, aim high and see how it can be achieved.
There are several ways to think about what a moonshot solution may be. One illustration is a suggestion that can significantly improve the user experience or result in considerable cost savings. It might also constitute an innovation in a new and unexplored product segment. Some examples may be as simple (in concept) as revamping packaging to game-changing new product ideas like self-driving vehicles (which could transform the way we think about transportation). Furthermore, it may be a whole new product category unknown to most organizations, yet it would be a game-changer for users.
Consider total accessible market (TAM) applications, which are based on the idea that a user should be able to access and purchase any product, regardless of brand or format. This strategy promotes organizations to create creative products that satisfy users’ demands in the most efficient way feasible. TAM is an element of product management since it may reflect a product’s full prospective user base. TAM also indicates how much competition a new product may encounter once it is introduced.
TAM calls for a comprehensive, integrated strategy that spells out both the organization’s overall goals and objectives for product management and the specific goals and objectives of products or services. Such a strategy entails creating workable strategies to accomplish these objectives, including defining success metrics (e.g., target market size or user satisfaction rates).
The key takeaways for the solutions phase are to examine TAM and moonshot solutions.
Consider starting with MoSCoW for how you assess at the most basic level. This approach for prioritization allows you to organize your implementation based on a must-have, should-have, could-have, and will-not-have principle.
Specific must-have projects are necessary during the lifecycle of the product. Consider them to be obligatory, not simply necessary. Having defined market and user profiles and understanding user needs might be examples of this. Furthermore, the product manager should track how user involvement changes over time since this information may be used to drive future investments in the product or changes to its roadmap.
Product management should-have initiatives are activities or features that should be implemented as standard in an organization’s products. They might vary greatly depending on the product, but some common examples include adding additional functionality to an existing product, creating whole new products from scratch, and refining user service policies. Of course, when it comes to their products, all organizations have distinct needs and expectations, so what is regarded as a should-have for one organization may not be suitable for another. However, there are several major aspects that every must-have effort should address: (1) product and technical feasibility; (2) economic sustainability; (3) legal compliance; (4) time constraints; and (5) ongoing organizational challenges. Consider the following as illustrations for each:
— Product feasibility: is the project possible and realistic given time, budget, and other relevant constraints?
— Product feasibility: is the venture possible and realistic given time, budget, and other relevant constraints?
— Economic sustainability: will adopting this initiative result in beneficial returns for stakeholders in the organization?
— Legal compliance: are there any regulatory criteria that must be completed for the development to happen?
— Time constraints: how long will it take to implement this venture from conception to launch throughout all aspects?
— Organizational challenges: does launching a new product category necessitate changes at different levels within an organization (e.g., marketing, product management, and engineering)?
Three (but not limited to) ideas for could-haves include (1) evaluating user feedback and implementing changes based on that feedback, (2) conducting regular competitive analysis to ensure the product is keeping up with the market, and (3) defining key success metrics for the product and tracking progress against those metrics.
Listening to your users and learning from their experiences with your product is critical. Based on this feedback, you can determine what improvements or changes are required to better meet the users’ needs.
Keep an eye on what other organizations offer in terms of product and feature offerings. Such insight will help you recognize areas where your offering may fall behind.
What goals do you hope your product will achieve? Once these have been identified, create an approach for tracking progress toward them. Measuring your progress will provide valuable information about how well the product performs and whether any changes may be required or needed.
Will not have
Initiatives marked “will not have” are those the team has decided not to pursue. This could be due to a number of factors, including a lack of resources or a lack of prioritization. For instance, if a product team is developing a new feature for their product, they may decide that developing an accompanying web-enabled solution is not a priority at this time.
There can be multiple advantages to pursuing will not have initiatives. For starters, it can help the team focus on what is most important. Second, it can help to avoid scope creep and keep the project on budget. Finally, it can potentially ensure that the user is not overburdened with features that they will never use.
Naturally, initiatives should periodically be reviewed as priorities shift and new information become available. In this way, the product team can continue to be flexible and agile in their decision-making.
If you have any recommendations for this post or suggestions for broadening the subject, I would appreciate hearing from you.
Also, here is my newsletter; I hope you will kindly consider subscribing.
If you enjoy reading stories like these and want to support me as a writer, consider signing up to become a Medium member and gain unlimited access to all stories on Medium.
As part of this multi-part series, here is my other post:
Also, I have authored the following posts that you might find interesting: