Product management might be one of the easiest professions to get into, but one of the the hardest to master. There’s no single framework, pathway, or process to become good at it — which makes the role highly dependent on the manual learning process over the years. That being said, it does not have to be a difficult learning process for everyone — below are the 17 steps I have found to be crucial in launching digital products, specially those that are interfaced for mobile applications and web applications.

Step 1: Ideation

All products are born in the mind of the product manager first, and then brought to life by the team. As you grow in your product role, you will start to find gaps in your company’s offerings, since you are constant in communication with your users (hopefully!) and you will start hearing common pain points and frustrations. Additionally, the following are acceptable forms of ideation:

• User Research and Feedback
• Feedback from Customer Support
• Data indicating need for a feature/product
• A strong gut instinct

That being said, a lot of Product Managers might find themselves in positions where they are assigned a product instead to build, and that is not an ideal position to be in. In that case, a product manager should first build a Business Model Canvas (BMC) and ruthlessly try and understand the underlying business value and user value for what they are building. Additionally, they must also be really clear on the ‘why’ behind what they are building, and how they are differentiated from competition.

Step 2: The Product Requirements Document

With a clear idea of what you want to build, you go ahead with the Product Requirements Document (PRD). The PRD is the single source of truth for all stakeholders in an organization

This is a classic object of product management, and there have been mixed reviews about creating a PRD. I am a believer in the PRD, since it allows for the relevant stakeholders to view information in one place instead of chasing after siloed information. Additionally, it is always rewarding to look back at what you assumed and imagined at the start of building a product and how differently it turned out in the end, and what you learned in the process.

Instead of going too deep in Product Requirements Document, I would recommend reading Epic Alignment — How The Best Product Managers Work With Feature Documents. I would also recommend using Delibr software for reference; the software has tremendously upped my PRD game and I recommend the software for everyone, specially since it is free.

Step 3: Product Roadmap

The next stage is product roadmap, and it is one of those things that took me a while to understand. The Product Roadmap is a visual representation of how the product will be delivered, and when. I recommend going through the Google Project Management Specialization, which really helped me understand how complex software are built and scoped. Work Management software like Jira and Linear are optimal for this kind of work. I prefer Linear since I find its UI more intuitive, but you can’t go wrong with either.

Start off by creating a new ‘Epic’ in Jira or ‘Project’ in Linear. List all of the steps from this article as separate cards or tasks in Jira or Linear, in Backlog. Then, go ahead and assign them:

1. Priority (Urgent, High, Medium, or Low)
2. The Task Owners (more on that later in RACI)
3. The story points estimate (don’t get hung up on this — you can start off by estimating a task on a scale of 1 to 5 in terms of time taken, and then move on to Fibonacci sequence later on).
4. The Due Date/Duration (again, this gets better with experience, so make a best guess).

Step 4: Stakeholder Alignment

At this stage, you are solid on the product roadmap and have mapped out the steps towards product delivery on the roadmap. It is now time to align all the relevant stakeholders for your product work. One of my favorite frameworks, the RACI stakeholder management framework, can come really handy at this stage.

By now, you should be getting a clearer picture of what you want out of your feature/product. Now, the time for determining the ‘who’ comes in. Start off by listing all the tasks you mapped out in step 3 and assign one of the following to each:

• Responsible: Who is responsible for doing the actual work for the project task.
• Accountable: Who is accountable for the success of the task and is the decision-maker. Typically the product manager.
• Consulted: Who needs to be consulted for details and additional info on requirements. Typically the person (or team) to be consulted will be the subject matter expert.
• Informed: Who needs to be kept informed of major updates. Typically senior leaders.

As a general rule of thumb, I like to keep the Product Owner and Product Manager/Senior Product Manager Accountable for all the tasks, with tasks such as the Ideation, PRD, and Roadmap being assigned as ‘Responsible’ for the Product Owner. Keep all functional heads ‘Informed’, the actual task owners i.e. Data Analyst, Designer etc ‘Responsible’, and their line managers i.e. Senior Data Scientist, Senior Product Designer etc ‘Consulted’.

Step 5: Communication Plan

After having completed your RACI stakeholder chart, you must set up your communication plan. This step is crucial for any product, since misalignment and communication do happen, and this step will go a long ways to prevent that. I like to divide the communication plan as per the RACI stakeholder chart, and decide on communication method according to options available. For example;

Informed: A bi-weekly written memo on all the updates on the product side.

Consulted: Primarily I leave this on the task owners to report to their line managers, but I occasionally tag them on Linear cards and Notion documents.

Accountable: Usually I, as the Product Owner/Manager am accountable for the outcomes, and or my direct supervisor, so a short, daily call is preferred.

Responsible: Every task owner should diligently update their work progress on relevant medium, such as Slack channels.

Step 6: User Journey Mapping

This step is where you start really building something tangible for the product. At this stage, you onboard product designers or UI/UX Designers and explain the product’s functionality to them. They will create a flow diagram, which will follow the actions and decisions the user will undertake when they are interacting with your product. This will bring immense clarity to your product, as you might realize that there is a lot of potential for improvement in your product as you initially thought about it.

Step 7: Low Fidelity Wireframes

Immediately after iterating and improving on your user journey map, you start with building low-fidelity wireframes. The low-fidelity wireframes will be a basic sketch of how your end product will look like. Although both, User Journey Mapping and Low Fidelity Wireframes are steps you can skip and go directly to what people call ‘rapid UI’, I would discourage against this since these steps are necessary to refine your product, specially when it is going to be released in front of your customers directly.

Step 8: User Acceptance Testing

Before you take engage your design team on a full-blown effort to creating the designs, it is fruitful for you to test your low-fidelity designs with your end users. No matter how excited, or in love with the product you are, reality checks are inevitable further down the line, and your judgement as a product manager will be called into question. Try to get your customers on call, or visit them in-person, and engage in User Acceptance Testing. Enlist the help of a UX Researcher if your company has that resource, and if not, just hop in a conversation with your users and document their feedback. Try to get their feedback implemented into the Low-Fidelity designs right away.

Step 9: High Fidelity Design

This is the final deliverable from the Designers, and it will have to be comprehensive. Depending on the the design team, they will have varying processes such as ‘Affinity Mapping’ etc. However, the main design file would be on Adobe XD or Figma, software that are suitable to build designs for mobile and web applications. At this stage, the UX writing, translations, illustrations, screen flows, and product instrumentation and analytics are also included, so it might take its sweet time.

Step 10: Handover to Engineering

After the designs have been finalized, they are handed over to Engineering for development. Although a handover seems to be a simple, banal task, it can be a source of immense friction. If you do not want Engineering and Design to be at each other’s throats few weeks down the line, ensure that everything is kosher yourself. Scrutinize every screen possible for any possible errors and typos or mistakes. Make sure all illustrations have been delivered in appropriate format, all screens have been included, and all edge cases are accounted for. Sign off on the designs with absolute conviction, because changing things after they are in production is like changing the tires of a car while it is running.

Step 11: Software Development

At this stage, your product is closer than ever towards becoming a reality. You must remain in constant communication with developers — try attending their daily standup if they are following Scrum or set one up yourself. Often, designers are ambitious with the possibilities and are not aware of the engineering limitations of their designs, so keep a margin of error for your application not looking exactly like it was designed, but it should not look too different. At this stage, keep a close check on what data is being collected by your application and ensure they are being stored in safely in correct tables and all events are being tracked and implemented.

Note: Some product managers act as de-facto product owners in their agile/scrum teams. In that case, you will be much more involved with managing the tickets for the Engineering teams and will be much more involved.

Step 12: Internal Testing

Congratulations! The engineering team has marked their Jira Tickets or Linear cards as ‘completed’ and you have a product. Take time to congratulate yourself and the team for delivering a (potentially) amazing piece of software. Now, although the software would ideally have been screened by ‘Software Quality Assurance’ (SQA) team, it is a good practice to release the software for internal testing. Paste the APK file (in case of Android) or the URL (in case of a web product) on Slack or whatever communication tool your company uses. Ask them as a favor to test the software and point out any bugs, confusions, and/or feedback. Document this rigorously, and improve your software by putting up tickets on your work management software.

Step 13: Dashboarding

Before you launch your product, make sure you have created the relevant dashboards to track your user behavior. The product analytics events that were accounted for while designing the product and implemented during engineering need to be imported into your analytics software. Mixpanel and Amplitude are the two famous software for this, and make sure you set up the funnel analysis correctly.

Step 14: Product Launch

Launching your product will be the next logical step. It is the step that you have been waiting for, and you will start seeing and tracking people using your products now. Keep a close eye on the analytics and see if anything appears odd. Additionally, this is also a time ripe for cyber-attacks if you are working on large scale products.

Step 15: Go-To-Market

This is the time to execute your go-to-market (GTM) strategy. Your GTM is the blueprint about how to reach your customers. The growth/product marketing/brand team will be collaborating with you on this throughout the product development process, so make sure you loop them in early. Ideate on the deliverables, such as a product video, banners, ads, etc and how the medium of communication with your end customers such as Push Notifications or In-App Automations.

Step 16: Retrospective

A couple of weeks into the launch of your product/feature, you will start getting a sense of how it will perform and will be in a good position to project how it will grow. Now is the time to sit down with all the stakeholders involved in your product, and ask for feedback to improve your future product/features. The following questions need to be definitely asked:

1. What did we do right?
2. What did we do wrong?
3. How can we improve in the future?

Keep an open mind during this phase and ensure that all the stakeholders are comfortable in sharing their true opinion.

Step 17: Iteration Loop

Developing and launching the product is just the start of your product journey. The real work starts now, with increasing your learnings everyday. Design experiments and interventions to tinker around with what works and keep improving every day, and keep in constant contact with customers. Explore the conversion rate for your product/feature and keep on working to improve it. However, this is just an over-simplification. My next article will be focused around the roadmap towards managing an active product.