by Roy Cobby
There are 7 phases of Product Development, and each one of them is vital to achieve success in product. You might have been in the business for a while, but this concerns you. It is not just PM textbook content; these stages have their own implications for your work. Improvising is good; knowing what lies ahead is even better.
Check out this guide to distinguish between development and deployment; be prepared to face the challenges involved at every step. Even the most experienced product people invest weeks, months and sometimes even years, into designing new and more innovative products that will hopefully answer customer questions, solve problems and make lives better.
Navigating the Phases in Product Development
Phase 1. Discovery
Objective: Find a problem to solve
Product discovery is the initiation phase, where the Product Manager talks to customers, listens to their feedback and pays attention to customers using competing products. Once you know which features are most valued to customers, the main goal is to obtain, validate and implement customer feedback.
There are two key perspectives: an inductive one; and a deductive one. How are they different?
With regards to inductive reasoning, this type of process seeks to develop a line of inquiry by looking at different sources of qualitative and (mostly) quantitative data. Thus, the starting point are usually surveys, documentation from previous projects, competition research, focus groups, semi-structured interviews and consultancy reports. These sources of information are based on processing large quantities of information to identify a gap in the market. Remember, this gap must not always be profitable from day 1: we can think about monetization later if the project is interesting enough.
There are certain problems with this perspective. Largely, that it merely seeks to extract what is already “out there”. It can be a long time before the different pieces assemble together into something truly original. In the meantime, a whole team of researchers has to be maintained and oriented. That is, only large organizations or financiers can really afford leading this kind of initiatives with a modicum of success. We are talking about the Apples and Googles of the world.
Deductive methods, on the other hand, rely much more on small-team creative sessions. They attempt to come up with an original idea; truly something that has never been thought of before. Here, methodologies are much more diverse: from intensive team-building experiences to internal company experiments; anything goes. The point is to amplify your sources of innovation: customers, partners or international markets can be integrated to the product ideation process and provide unexpectedly exciting ideas. This makes it particularly attractive for startups, as the number of resources you have is not necessarily what will determine your product’s success. It is all about ideas!
One example is the Jobs-To-Be-Done perspective. JTBD, rather than thinking in terms of “solutions” (solving a problem for users), thinks in terms of jobs or tasks. That is, while developers might have an established conception of why they are building and upgrading their product; possibly customers will think otherwise. Your external stakeholders could be employing your task management application as a sales call solution, for example. What if your developers work hard at expanding your solution horizontally, moving towards those areas where your product is already providing a service?
That said, both inductive and deductive reasoning are often employed in tandem. Any seasoned Product Manager should be able to know when to use one or the other.
Phase 2. Define
Objective: Determine the MVP – (Minimum Viable Product)
The goal is to have a product that has the minimum set of features to test key assumptions. In this phase, it is important to not waste valuable resources where they are not necessary. Work until you get a solid understanding of the problem to solve and the needed features.
Determining the MVP is not a straightforward process. Seasoned Product Managers might trust their instincts. But, for those with less experience, it is much more important to have a system. For example, Sprints provide a quickfire working model that forces teams to think on their feet. Over a short period of days, the different functions meet together. First, they determine their own contribution to the overall effort: how much and for how long can they get closer to the desired objective? Then, they share their impressions with the group and, through open discussions, they come up with an achievable set of Objectives and Key Results.
Whether you rely on Sprints or other methods, determining the Minimum Valuable Product should not worry you excessively. Indeed, one advantage for product managers is their discipline’s connection with the digital revolution. In the past, Project Managers were involved with fulfilling certain deliverables with a beginning and an end. Once the project was completed, project people moved onto the next one. This way of working relied on a conception of “finished” projects that do not match the digital world.
In fact, Product Managers understand that their work is never really finished. The day after they release anything, they are again thinking about how to add or remove features. Thus, the whole MVP process should be more dependent on the availability of resources, as defined by internal stakeholders, than the real product “needs” (which are always changing).