Project Management Archives - The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career

Master Product Launches using this Product Launch Email Template

Joseph Akoni — Thu, 20 Aug 2020 04:05:43 +0000

You’ve planned, designed, developed and are now ready to launch your product! You have to let your company know of the launch, right? Use this template to guide you in alerting all stakeholders within your company of the imminent product launch so everyone can track the launch’s success!

Link to template

Want to learn all the steps you should undertake to launch a product from start to finish? Read the Q&A between Andrew Mairena (MoveWorks PM), Chandrika Maheshwari (DocuSign PM) and Joseph Akoni (LinkedIn PM) as we discuss the tips and resources we use to launch a product successfully from start to finish!

The post Master Product Launches using this Product Launch Email Template appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

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

Joseph Akoni — Sun, 16 Aug 2020 21:25:42 +0000

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.

Additional Resources

Launch email templates to share product launch details with the relevant members in the organization

How Might We toolkit to understand and apply the technique properly

Best way to write a PRD with examples from top tech companies

The post Q&A: How to launch a product successfully from start to finish? appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Master Communication using this Weekly Product Update Template

Joseph Akoni — Sat, 25 Jul 2020 08:57:17 +0000

Communicating consistently and providing detailed updates on product progress will save you the agony of hearing “Wait, you haven’t shipped yet, why?” Or “What have you been doing the past two weeks?” These are two questions no Product Manager (PM) wants to hear (Trust me, I’ve heard them). Remember, excellent communicators are not born, they are made. If you are new to the PM role or simply want to improve your product update communication skills, this post will help you on your journey to be a master communicator.

Want to jump to the template?

CLICK HERE

_______________

FAQs

How to use the template?

The document is organized by week and then broken down by function (Engineering, Design, Product, etc.). It uses reverse chronological order in which the most recent week sits at the top of the document. For each new entry, simply copy, paste, and update the previous week’s entry.

What is a weekly update?

The weekly update provides details on all things past, present, and future related to the product. These details include:

1. Important Tasks/Meetings (in progress, completed, or upcoming)
  - Do you have to update the metrics being tracked? — Write it down!
  - Do you have to set up a follow-up meeting with a different cross-organization product team to ensure commitment? — Write it down!
  - Do you have to conduct user research to validate a current assumption before deep diving into the feature solution? — Write it down!
  - What’s the status of the major API integration work? — Ok, you get the point.
2. Important decisions made with respect to your product.
  - Did you finalize the product design specs?
  - Did you decide on a company/public release date?
  - Did you include a new design/engineering feature to increase engagement?
3. Important Updates
  - Is there a blocker that just appeared which added a new engineering requirement
  - Have you created a solution to remove a blocker which will accelerate the development timeline?

Note: All details should be broken down by function (Product, Marketing, Engineering, Design, UX Research, etc.). This way each stakeholder can dive into the section that matters to them, or read other sections at their leisure.

Okay, Where can I get my hands on this gold!?

CLICK HERE TO GET TEMPLATE

Who should receive the update?

Anyone involved in your project. Depending on your product’s priority, scope, and current stage, these stakeholders can be:

Your Manager – ALWAYS include your manager
Your engineering partners
Your engineering partners’ managers
Your design partner
Your design partner’s manager
UX Research
Other PMs (if collaborating with other teams)
Marketing

Do I have to send this out weekly?

It depends on the priority, scope, and expected completion timeline. For high priority projects and projects in which engineering work will take more than 3-4 weeks, I recommend one week update intervals.

When should I send this out?

Preferably before any major meetings occur for the week. For example, if you have a working team sync on Wednesday, the latest update should be sent out before Wednesday to ensure everyone is on the same page with all items that must be discussed on Wednesday.

Tips before sending out weekly updates

Create an email listserve of all stakeholders, so you don’t have to type in every email of every stakeholder every time you want to send the update.
Verify all progress that you noted is true. Do not commit your engineers or designers to tasks they never agreed to. Your engineers or designers may distrust you as a result, repairing that relationship might take time that you don’t have.
Ensure you have the latest information as of the day you sent it out. Nothing makes people trust your update less than receiving an update on the update from someone else immediately after you send your update.

Why are updates important?

Keeps you organized and updated on everything happening within the product development. You’ll coordinate meetings about everything from requirements definition, design decisions, engineering, cross-team collaboration progress, and marketing communications. In order to stay in sync with all this information you are gathering, you must be organized. Additionally, sending out updates communicates to your team that you are organized.
Forces you to ask questions and listen intently during every meeting. You have to create and send out a weekly update, which means you must know specific details on everything happening. How do you ensure you get all the necessary details? You ask questions and listen!
Lets everyone know you’re listening – Everyone likes to feel heard, ensure your team feels they’re heard.
You’ll forget things – and occasionally YOU (yes the person who wrote the update) will have to review the weekly updates to remember exact details because you may also have a newborn, 5 exec level products, and a thought in your mind about what snack you wanted to eat out of the micro-kitchen. Who can balance all these at once ALL the time!?
Helps promote product progress. Even if there’s a roadblock, noting that a workaround is being completed is…PROGRESS! Everyone likes progress, trust me.
Keeps everyone abreast of product progress – No one can claim that they did not see the 10 emails you sent out at the same time on the same day describing everything that is happening with the progress of the product.
Builds trust within the team. Everyone on the working team trusts that you are accurately communicating information to all stakeholders. All other stakeholders trust that you are tracking all tasks and will ensure the product launches.

I also posted this on the Almanac.io website. It’s a great resource for templates of all varieties across numerous roles and functions.

The post Master Communication using this Weekly Product Update Template appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Master Communication using this Daily Product Update Template

Joseph Akoni — Mon, 20 Jul 2020 10:33:20 +0000

Have a product that needs to be shipped out URGENTLY and, therefore, requires daily communication to all involved stakeholders? There’s a template for that! The link is below. Feel free to edit it as you see fit!

CLICK HERE FOR THE TEMPLATE

Do you also want to track product progress on a weekly basis?

The Daily Product Update Template can be used in sync with the Weekly Product Update Template. You can find it in in the article titled “Master Communication using this Weekly Product Update Template“

The post Master Communication using this Daily Product Update Template appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.

Master the Product Requirements Document

Joseph Akoni — Mon, 20 Jul 2020 09:37:03 +0000

The Product Requirements Document (PRD) is the one-stop-shop for everything related to your product/feature. Some of the sections include:

Overview
Outcome
User Requirements
Open Questions
Metrics
Link to UX-design mocks

Every PM (even PMs within the same company) have their own way of creating their own PRD. There is no standardized way. Access the template in the link below and edit it to your preference.

Link to template

The post Master the Product Requirements Document appeared first on The P-Zero PM - Tips and Tools to Ensure a Successful Start to Your Product Management Career.