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.
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).
Phase 3. Design
Objective: Defining and designing
We have the solution to a problem. Now we need to design it. This is the phase where designers come in strong. The PM works with them to create mock-ups. They meet with customers and get their feedback on what works and what doesn’t, and the mock-ups are tested with customers. This process is repeated until there is a well-defined product that solves key problems for customers.
One of the most important elements at this stage is to come up with a roadmap. Roadmaps are graphic displays of information, where the whole journey from drafting to releasing is reflected. They reflect the product vision from a conceptual and technical point of view and serve as the reference point to assess whether goals are achieved. This document should be produced in collaboration between designers, marketers, and engineers.
When it comes to considering these points, the Product Manager must remain an open communicator. Between and within teams, openness is really important to achieve alignment. A bad design is often the result of bad planning. Finally, User Experience designers might have a keen eye for customer use of your product. But the only professional who is really aware of how this connects to the larger project, is you. Features might look clunky or easy to discard from a designer point of view; however, as a Product Manager, you will know whether it does or does not make sense to remove them.
Phase 4. Implementation
Objective: Construct results
The implementation phase is where developers, engineers, and the product manager shine. The product is designed by developers, understood by engineers, and kept on track by the project manager. The engineers test the look and functionality against the product the developers have created to make sure they match.
The Product Manager is involved to prioritize features, create product specs and see and use the product, to make sure it passes requirements. From there everything is passed to the project manager to make sure development runs on schedule. This collaboration is really important: project managers are particularly aware of time and economic constraints. At the same time, they might be too zealous to take control. Like with any other internal stakeholders, make sure to develop a good relationship with Project Managers and your superiors.
One important consideration of the implementation phase is to hold regular meetings at the beginning or the end of every day with the different teams. Many Product Managers who come from non-tech backgrounds find it intimidating to engage engineers. However, in the tight constraints of product development, a timely intervention can save you a lot of work in the long run. If you need to strengthen your self-confidence, working on your coding abilities can do wonders for your communication.
Phase 5. Marketing
Objective: Define marketing goals
While we might be listing this stage quite far on the list, you should actually involve marketers from the very start. Their particular knowledge of your target customers, the market and the sector is fundamental. Most of all, your product itself and their narrative to sell it must be coherent. It is not about them having a head-start so they can work on their copy for a longer time: it is about both the product and its marketing strategies screaming the same messages.
An important role in this process is the Product Marketing Manager. These professionals often work underneath Product Managers, and they work as the point of contact between the marketing team proper and the more technical side represented by the Product Manager. PMMs are becoming increasingly important in the industry because they share the product vision with the PM and help to bring it home across blogs, videos, and other promotional material.
The PM, however, has the last word. There is nothing worse than an over-hyped product; there are plenty of cases of Silicon Valley enthusiasm that melted into nothingness. Product Managers, since they have undertaken all the previous necessary steps, are aware of their potential and limitations. Often, a truthful, simple and direct campaign works better than the big announcements associated with the tech industry.
Phase 6. Training
Once we have the final product, we need to tell people how to use it, internally and externally – to customers. Training material is created for internal and users. The PM would also write documentation on how to use the product features.
This process need not be boring. We are not the corporations of old, after all. You can elaborate creative materials that reflect your achievements. If you have developed a software that helps one particular sector, for instance; why not involve them in the launch? Piloting your solution is the best way to know whether it works. Plus: your training might write itself!
Another important factor here is to build love for your product – internally! You might be based at a small startup where your development has been the main activity. Then, this is not so important: everyone should already be professionally and emotionally attached to your project! If you are at a large firm, on the other hand, creating an internal constituency of backers is extremely important. You should use your product community to achieve this.
The reason why this is important is twofold. First, if you are satisfied with your product, you ensure that all eyes are on you. You are probably taking for granted that everyone is aware of what you have been working on. Wrong! Work hard at selling your ideas, explaining your story, translating it into achievements. This will be particularly good if your product is a success. Secondly, if your product is not a success… involving a few decision-makers before launch is vital!
You might think that this is counter-intuitive. After all, we would all rather hide our mistakes! Quite the opposite: if you get some buy-in from upper management and experienced colleagues, you will receive that last-minute advice which will help you take your product to the next level. That sort of professional involvement will also protect you should things go wrong. All in all, you are guaranteeing that your project is not misunderstood; and that is judged on your terms.
Phase 7. Launch (Party)
Objective: Send product to market
Finally! We are done. The product is where it needs to be. Potential users are aware of its existence. Current users are well-serviced by it and a dedicated team of Customer Success. Executives are out in conferences and marketers are reaching out to specialized publications to talk about your most recent success. You can change into your regular clothes and ride towards the sunset…
Finishing well is as important as starting. Remember how at the beginning you sat down with the different teams to discuss achievable goals? It is time to compare them with what you actually attained. If they have been surpassed, no problem! If you did not make it, you need to come up with as many plausible explanations as possible.
And, remember: a product is never really finished!
Product Development Phases: Phased Out?
These stages involve the classic steps in Product Development. As such, they provide a workable template for aspiring PMs to understand what product development involves. It is also a good way for experienced PMs, often lost in their daily battles, to reflect on the challenges they usually encounter and whether there is something they can improve.
On the other hand, the most advanced product operations might be working with alternative formulations to this very general model. Perhaps there is one stage they simply ignore; or an additional one which helps them reach new heights. Whatever works, right?
Is there anything you do differently? Let us know!