Products can be approached in a variety of ways, ultimately leading to the same outcome. But is that outcome actually the same? We end up with a product that reflects the customer needs and end-users are engaging with the product. Success, right?
What isn’t apparent is the work leading up to the product launch and if the process had the appropriate timeline, communication and collaboration required to be efficient and effective.
Roadblock in the Product Roadmap
What is the worst that can happen? By not taking into account the risks associated with launching your initiatives, you may very well end up running out of time for a market release, or worse, release something that does not actually achieve the right impact to your target audience. The good news is that there are ways to mitigate this risk.
Do we have a clear sense of the problem we are solving? Do we know who the target audience is and does it align with our business objectives? Is the product integrated with the other technical aspects of the business? Is the code or product scalable across the organization or market? How did the process affect the overall budget?
We have embraced the concept of Agile, which can lead a team down a very slippery slope if not used in a way that benefits the organization as a whole. This is when it is helpful to engage with more formal product processes to ensure resources and priorities are maintained, especially when balancing multiple projects at a time with a limited set of resources.
When approaching a new project that involves design, development and a number of stakeholders it is important to support the team and keep everyone engaged in the initiatives.
However, every team is different.
What I have done on projects over my career has since evolved into a more free-form, team-specific system requiring a Product Manager to lead the individual efforts between departments and piece together the various discussions into formal requirements. This definitely has it’s opportunity for complications, so I have developed six key phases to a successful product process to keep me on track.
So what is this process?
Initiation happens when the project is originally conceived. This is most likely based on business objectives, market research and data collected from new and existing customers. Worst case scenario, you are told to do it because someone thinks it is important without enough data to back it up (note this can be a symptom of Shiny Object Syndrome). In any regard, an idea is born and it has been prioritized.
When scoping a project, a product manager is tasked with knowing the business requirements in order to communicate across the organization. That being the case, the outcome of this phase should be your problem statement articulating the what, who and why of the initiative.
Your problem statement will now be your guiding force as you begin scoping the project.
Identification of what it is you’re building is essential so that cross-functional team members can refer to the documentation agreed upon by the various stakeholders. Identification also provides the opportunity to gather team insight into additional requirements that will be used to scope for potential scalability.
The outcome of this phase should have identified the Minimum Viable Product (MVP) to fulfill the initial problem statement.
If I can give you any advice on defining an MVP, it is to know what criteria would make it successful at a minimum and why. Once you have identified those, keep them in mind throughout the project. Many “MVP’s” can either take on more scope than necessary or have stripped everything of value ultimately dooming the effort from the beginning.
When you begin gathering requirements, make sure you know what it is you are trying to solve. For instance, I was working on a feature request that identified the need to have additional contacts associated to a feature in a product in order to receive notifications. Through conversations, we were able to identify about seven potential user roles who would want to receive a notification, but at different stages in the product workflow.
This increased the scope from adding a contact, to also accounting for additional user types and notification trigger points/messaging within the product. Taking a step back and refocusing on the initial problem, we defined that at a minimum, what could only be done by an internal admin should be enabled for the customer admin so that at least any user associated to the customer account would receive our standard notifications. This reduced the larger scoped effort into something more manageable and still fulfilled the initial problem of assigning contacts to the feature.
This example identifies the value in having a clear problem statement to refer to so we could maintain focus on solving the problem without wasting additional effort to achieve our success metrics. And with time and money being so valuable, why waste any!
This phase focuses on team consensus of the project before beginning any development. At this point, the product manager would create the user stories and acceptance criteria, as well as request related assets from the team required to execute on the effort.
Consensus is critical as it removes any hidden assumptions and unvoiced expectations that may exist within the team. All project members must be involved in this process to confirm that they understand the effort at hand and the team has highlighted potential assumptions for further clarification. The close of this phase has sign-off on requirements, including visual assets, as being actionable. Additionally, you should have a sense of timeframe in order to deliver on this initiative.
Once the requirements reach a consensus among team members, we can move the project through to the Execution phase. It is very important to note that these requirements will also be the point of reference for developing the quality assurance script for expected outcomes of functionality and implementation.
Without proper documentation around styles, site templates, functionality and future scalability, there is no clear set of acceptance criteria when validating your product prior to launch.
Iteration is not a phase in and of itself. Instead this is a process that involves continuous collaboration and communication with the team and stakeholders. As the initiative progresses, new constraints, concerns and potentially new data have the ability to affect the end result of the project.
This is where Agile becomes an active part of the process to ensure that what is being developed is lean with the potential to quickly pivot as needed. Rather than taking a Waterfall approach, Agile influences the product development process in a way that reinforces continuous conversation throughout the stages of this process.
This means that the product manager continues to keep their eye on the strategic vision, while also being able to break down the effort into small, executable components that is discussed and actionable by the team. Iteration feeds into the Launch phase in a way that prepares the cross-functional stakeholders to know what is being delivered and when.
Depending on your development methodology of choice, the effort may take multiple sprints, have a firm date or a more fluid monthly/quarterly/yearly based target.
In preparation of a launch you will begin preparing for the release of your initiative, including internal training, customer facing tutorials, market materials, etcetera. Your timeline for having these deliverables met will depend on your release date, accounting for the required amount of lead time.
Congratulations! You are ready to release your new product or feature to your target audience!
Product Managers should be able to straddle the tactical aspects as well as the strategy of the business. By staying actively involved in the process, and having a clear set of goals from the Initiation phase, you should have been able to make the appropriate decisions based on thoughtful communication and collaboration. This will enable you to achieve product success.
Featured Image from Flickr contributor