Project Management

Q&A: How to launch a product successfully from start to finish?

By: Joseph Akoni

Special thanks to PhotoRoyalty for providing the featured image

I had the pleasure of collaborating with rockstar PMs Andrew Mairena and Chandrika Maheshwari from How To PM to discuss tips and resources that each of us use to successfully launch products at our respective companies. Andrew is currently a PM at MoveWorks and Chandrika is a PM at DocuSign.

Note: How To PM is another site that provides great tips and tools in a Q&A format to help new product managers become successful! Check them out!

Product Management is not a science so there are many processes available that will help you accomplish any single task. Read the Q&A below to get insight into how PMs at three different companies (DocuSign, Moveworks, and LinkedIn) each tackle launching a product from start to finish!

You can read the article on this site below or check out the article on the How To PM website.

About us: Andrew (AM) and Chandrika (CM) met during their MBA program at MIT Sloan and connected over their passion for product, growth and paying forward the help they got transitioning into product management. AM currently works as a Product Manager at Moveworks and CM works as a Product Manager at DocuSign.

For this post, we have a guest editor, our friend Joe Akoni (JA) who is a Product Manager at Linkedin, working on the Identity (Profile) team and recently launched a very beloved experience – the Pronunciation Feature. Also, Joe is the Founder of P-ZERO PM, which is another great resource to provide essential tips and tools for aspiring and novice PMs.

In our previous post, we focused on the prioritization frameworks within various companies, from a 150-person start-up to a 840,000-person tech giant. Despite the varying industries and company sizes, each of us shared our unique ways of prioritizing potential projects. As a next step in the process, we will now share our experiences of refining the problem statement to obtain alignment to executing towards an effective product launch.

Q1. How do you define the problem to drive alignment within the team?

ANDREW: I have found two different ways to define the problem statement, whether its a customer-facing product or an internal product. For an internal product, I just follow a simple framework for a bottoms-up approach – observe, interview, and define (the problem).

To start, I simply observe behavior by participating in the activity that needs improvement. I always try to do one of the tasks to experience the pain points myself.
With some opinions developed, I then conduct interviews with targeted questions, trying to get concrete anecdotes of user pain points and drill down to the root causes. Some people call this “5 Whys” and others call it “First Principles Thinking”. By getting into the core of the problem, I realize that multiple root causes can contribute to a single problem.
Finally I write a short memo on the problem statement, attempt to size the problem, e.g. time loss, etc, and identify the root causes.

Through this collaborative process, I was able to build consensus on the problem statement while reassuring me that I understood the underlying mechanisms of that problem. Also, socializing becomes evangelising – It is the job of the Product Manager to get stakeholders bought into the problem so they want to be part of the solution.

CHANDRIKA: To kickoff a project, we typically start with the “How might we” framework by answering these four questions and then using the answers to generate a shared and comprehensive problem statement.

Q1. What is the customer problem we are solving?

Write this is first person, thinking as the customer

Q2. What is the business problem we are solving?

Focus on business impact, typically how it translates to a financial business metric

Q3. What change in the customer behavior would indicate the problem is solved?

Focus explicitly on customer behavior

Q4. Which customer segment should we focus on FIRST?

Who is so critical that the whole thing falls apart without them? Who is the core customer here?

From the answers to these questions, we then define our final problem statement:

How might we help (Answer to Q4), that want (Answer to Q1), to (Answer to Q3) so that (Answer to Q2).

An example of this in case of a food delivery app – The team has uncovered an insight that users who place an order the first time they log in have a higher lifetime value (LTV) and the team is trying to maximize the user LTV:

The customer problem is “I want to order takeout that is cheap and has the shortest ETA”
The business problem we are solving is getting users to order on first login so that they have a high LTV
The change in customer behavior that would indicate the problem is solved is the user places an order the first time they log in
Customer segment we want to focus on are first time users

How might we help first time users , that want to order takeout that is cheap and has the shortest ETA, to order the first time the user logs in so that the user has a higher LTV

JOSEPH: The most interesting way in which we define problems is literally through direct member feedback when members use the platform. Externally, users either directly tag LinkedIn PMs that they know or even tag our CEO, Ryan Roslanksy, to posts about features that we should implement on the platform. Internally, we conduct user research by talking to members, asking them to go through various workflows, and understanding their pain points. We also come up with potential solutions based on aggregated member feedback on currently released products. After identifying the problem, we define the metrics that this new member behavior will drive. I connect with various stakeholders such as engineering and design on a one-on-one basis. This is important because I am able to communicate to each person individually (and in the way that most appeals to them) why the problem is important and why the team needs to solve it now.Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.

Q2. How do you gather requirements?

ANDREW: For customer-facing products, I write a PRD-like document, which includes a list of pilot customers (sorted by headroom), goals, risks, and milestones. The document is then socialized with all internal stakeholders. When I socialize the document, I usually gain additional insights into the problem from an engineering perspective providing insight into possible solutions. Sometimes, there could be underlying ENG work that would take longer to implement than the product itself, which can delay timelines. If that is the case, then a quick proof-of-concept can be developed to at least prove out the idea, once it’s in the customers hands. The point is that these learned ideas are only through conversations with ENG, UX, and other stakeholders. I don’t let the PRD become stale but iterate with the team’s input.

CHANDRIKA: For large projects, we first conduct user research and follow it up by workshops with extended team members. In these workshops, the team comes together to share their input on what the requirements should be for the end state of the product/feature. In the remote world, we do these with whiteboarding sessions on a visual collaboration tool – Miro (screenshot below).

For these workshops, we typically curate a list of high level problems that we need solutions for. Everyone in the workshop gets a few minutes to brainstorm and write their solutions on sticky notes. Each member then gets to vote on their choice of top 3 solutions for each problem.

At the end of these workshops, we have alignment on the desired end state and top solutions that get on to the product roadmap. The next step is to translate these priorities into a PRD and then go through a couple of iterations on the PRD after getting feedback from key stakeholders.

For small projects, we would skip the workshop and I would start with an initial draft of the PRD, iterate on that and finalize the requirements after getting feedback from the Eng lead, UX lead, Sales/Marketing team and other key stakeholders depending on the project.

JOSEPH: My approach is to write the PRD and evangelize the idea by having verbal discussions with each stakeholder to get them excited about the feature and to uncover more detailed product requirements through these discussions. At a high-level, the PRD addresses the following questions:

What the problem is?
How do we want to solve it?
My initial list of product requirements
Which teams do we need to work with to solve the problem?
How can other product teams within the org leverage it?

Within the PRD, I propose a high level solution and work with the designer to get insight into design changes needed to accommodate the solution. Once that is validated, I socialize with engineering to confirm that the solution is implementable. I then evangelize the feature to other stakeholders like marketing/PR and User Experience research in case they have additional insight to provide.

If another team needs to be involved, I follow an internal process to get the necessary work on their roadmap. For example, as the PM for the Profile team, I would contact the PM of another team and convince them that the Profile feature would also benefit their product. As I speak with each stakeholder (design, engineering, marketing, research, other product team PMs, etc.) I gain insight from a different perspective which allows me to continue to refine older requirements and define new requirements. I present the final list of requirements during a ceremonial Product Kickoff – a short 30 min presentation for the individual contributors (ICs) to answer any remaining pressing questions before the team starts building.

There are plenty of resources out there to help with writing the Product Requirement Document (PRD). Here’s the P-Zero PM PRD template but also check out the ultimate guide of all templates that @lennysan had compiled.

Q3. What do you do while engineering is building?

ANDREW: At this point, I have identified the Product that needs to be built. While engineering is building it, I do other tasks to help set up the launch for success. Some activities include:

Analytics: Working with them to define the right, measurable metrics. If something cannot be measured, that is a good callout to see if DEV work needs to happen. Also, we work together on building internal and customer-facing dashboards.
Marketing: Within enterprise, it’s vital to obtain proof points as you consider rolling out your product in pilot. Having that conversation early on allows me to identify the first pilot customers who can fit the narrative well and be a good “first customer” user.
Configuration Documentation: I write internal technical, configuration documents for Customer Success Engineering so things are described clearly for implementation.
Customer Collateral: A brief one pager to highlight the product and its value so that Customer Success Managers can obtain buy-in from customers.

CHANDRIKA: In the time when the engineering team is building I’m usually focused on:

Working with UX researchers to finalize the research protocol for prototype testing (if required). For certain projects, especially where we are introducing a change in the UI, we typically do prototype testing to validate what we are going to build will be valuable for users.

Aligning with the data scientists to make sure we have defined the right KPIs to measure the impact of the project. Without the right metrics and measurement in place the impact of your work will be lost, no matter how hard you and the team have worked on the project or how great the product that you ship is.

Defining the instrumentation spec to ensure we capture the right data. For the instrumentation spec, I try to be as detailed as possible since without the right instrumentation we could lose time if we are not collecting the right data to measure the impact based on the metrics we define.

Partnering with the marketing team to define the GTM strategy. Typically I would work with the team to align email campaigns or webinars with the launch of the product/feature to amplify the launch response.

Informing the technical writer to update any support articles or documentation. If the launch changes the user workflow, we would update the documentation or articles available on support site.

Working with other stakeholders (depending on the type of feature and areas of business it touches) like Legal, Privacy assessment team, PR, Finance, Pricing, etc.

JOSEPH: Even while engineering is building the product, I am always communicating with my engineering team to track progress in case any new product or design decisions need to be made. For bigger projects, I set up weekly meetings with my design and engineering counterparts. For every project, I’ll create a Slack channel with all of the individual contributors (ICs) so that we maintain communication in between the weekly meetings. By including all ICs (design, engineering, marketing, etc.) it ensures that everyone can see all updates as we continue to make progress. For example, the engineering team may stumble upon an issue which requires additional product input that may lead to an updated design that your designer will need to create.

I also work with the data science team to ensure we have properly defined the metrics and are prepared to track the metrics accurately upon product launch. The one critical area that people may overlook is the help center article. For every product launch, I work with my product operations counterpart to ensure members can have step-by-step instructions on how to use the product. For instance, we put together this Help Center article for the name pronunciation feature. In addition, I work with marketing and PR to plan any potential marketing campaign or press release for the feature. For example, I worked with our PR team to write a Linked blog titled “Help Others Pronounce Your Name Correctly” and a post in WSJ that described the new feature.

Q3. What final checks do you make before your product/feature is going live?

ANDREW: Within a pre-prod environment, I aim to test four things: integrations (can our product make changes in the customer environment?), machine learning (does the results in the customer environment match the results from the holdout or test set?), analytics (is the data flowing the way we anticipated?) and the full E2E test (does the product or feature do what we intended?) Essentially, we always modularize and test each component of the product before we put everything together. Once confirmed in pre-prod, then we are almost set to test and then roll-out in prod.

CHANDRIKA: As the final check, I usually go through the following list:

Work with the QA engineer to do end-to-end (E2E) testing on various environments before the feature goes live
Organize a UAT (User Acceptance Testing) session with the rest of the team to go through key flows and look for any high priority bugs
Revisit rollout plan and key dates with the engineering team

JOSEPH: There are various stages that occur to test product functionality before releasing the product to the public. First, the engineers working on the feature run tests to validate functionality according to the design and product specifications that were initially distributed to them. Next, the core development team (designers, product managers, and engineers) test the feature across various devices to ensure no bugs exist. Next, the broader team/organization (including other designers, engineers, marketers, product managers who are not directly working on your specific feature) will test the feature before enabling it for the entire company. After the feature is released for all company employees to test, a phased roll-out plan to the public is initiated, where we begin launching it to a subset of total members (starting from as small 1% up until it is fully launched to 100% of all global members). Throughout this process, we track bugs and develop a mitigation plan in case any issues occur.