I joined Productboard to help form a Growth Product team from scratch and define the PLG motion. Productboard is B2B so "growth" is somewhat different - there weren't any established playbooks for B2B PLG 2-3 years ago, so I joined to help figure that out.

Growth talent is very hard to find. Sometimes you may need to find people who are good at other product areas and teach them growth principles and how to operate in a PLG environment, or vice versa - folks who have done growth work but not specifically technical product. I had a mix of characteristics and attributes on the team.

When I wrote this doc with my engineering manager, we were building out these teams and saw different ways of working emerging and causing conflict. We wanted to level-set expectations of best practices and also implement some checkpoints between Growth leadership and team leadership to ensure teams were working efficiently.

This process is somewhat similar to the core product org's, but there are some adjustments that I made. For example, we didn't really have user research as a function until much later, so I wanted to help people better separate the problem discovery step and the solution discovery step. Another example is the results review; it's not as if a core product team shouldn't be doing this, but the frequency and the way a Growth team reports out results is different.

We iterated on v1 by splitting the Research Plan and Research Synthesis steps into separate steps, and adding the Results Review step.

Another adjustment we made is to suggest ownership for different parts of the process. There are some designers who just want to design what PMs tell them to; some engineers just want to build what's in the spec. We wanted to instill a culture of ownership across functions and needed to set those expectations and have those conversations upfront.

To develop this document, we did a team workshop where we asked different functional areas to figure out a RACI or DACI model for each step. We highlighted the agreements and disagreements. There were some disagreements about who does what and who owns what. Then my engineering manager and I created a draft proposal and asked people to comment, respond to things, and have discussions. We held another discussion to solidify key elements. Every time a new person came on the team we revisited this.

While we wanted to standardize this process somewhat, the document is not meant to be prescriptive. We're not trying to force everyone into a single file line, but it's there to provide guidance and set expectations. This is especially important for more complex strategies or projects.

A pet peeve of mine is when teams don't actually separate the problem from the solution. We get really excited about building the cool thing, but don't take a step back and look at why it's the most important problem to solve right now.

For context, we do continuous research (exploratory analytics, weekly calls with different customers) on the team, which we can use as sources to identify new problem and opportunity areas. Every quarter during planning, we discuss whether that opportunity aligns with our current strategy and whether it should be prioritized. That is step 1. If we agree to prioritize a project, it moves to step 2.

At Productboard, the Growth org is called a "tribe." Tribe leadership consists of the head of growth, director of engineering, and the design manager.

This refers to the feature object in Productboard.

I tell people to be very casual for these presentations. I want to lower the barrier of entry to get my team members to sign up for these slots and get feedback. People might be too scared or feel really nervous. I don't want our team to do too much extra work for growth leadership, so I tell them that they're free to present via Figma or a Notion doc directly. The format doesn't matter and they can show works-in-progress, but I do expect people to frame up the conversation (e.g., the stage and the type of feedback they hope to get).

If the solution is straightforward and small in scope, you don't need a research plan. If it's more ambiguous or larger in scope, then you'll want to put together a research plan to detail what is known and what is unknown. This is an area where it can help to present to Growth leadership; we can help teams bring up relevant research/insights or tell them to narrow the scope of their research plan.

I tend to think problem discovery and research should be owned by Product but solution research should be owned by Design. If problem discovery was not done well or more needs to be done, then the team should move back to Step 1 (driven by Product Manager). If there is confidence in the problem and strategy, and research is needed to give input on the solution, then it should be driven or delegated by Design.

I think things like usability testing should be owned by Design. Once you've had some problem research already done, Design should own how to continue the research in a more specific way to get to the solution. They're going to need to do that or else they'll be designing in a vacuum. It doesn't mean Product shouldn't do anything, it's just that someone should own driving it forward. I want to make sure people are feeling accountable to the whole process.

Product Marketing is mentioned in the case that we want to research specific personas or as it relates to pricing & packaging.

If Design isn't convinced about the problem, then it goes back to Step 1 and PM is responsible for justifying.

I don't see this happening that often though. This is more of a back-stop.

The other thing that I see a lot is when teams do research, there's a step in between doing research and defining the problem, which is synthesizing the research. Oftentimes, I will see people say "here is the problem" and the evidence is instead an amalgam of research that is hard to consume. I tell people that they need to synthesize it into a conclusion with supporting evidence (just like the traditional 5 paragraph essay format from grade school!). People forget those fundamentals and claim "here's the problem", but they haven't convinced me yet because they haven't synthesized the research.

We also send these summaries to Productboard, where you can tag them, organize them, and send it to other members of the team.

In most cases, Product and Design should divide and conquer different research questions or different methodologies (e.g. analytics versus customer calls). They come together to share information and synthesize the learnings together with one set of takeaways.

I require every member of the team to share summaries of their research in Slack, however small. It forces them to articulate key takeaways and gets great engagement from the broader org, especially those in other functions.

"Medium-large" typically means something that is 2+ sprints, but it really depends on the context of the team and how much they've been working together. If they've been working together before on this domain area, they may not need this explicit step.

This is a messy process and involves discussing various explorations and options. I expect Product to help facilitate the conversation since they ultimately have to control the scope. Teams run into trouble when designers have difficulty grasping technical constraints, engineers aren't UX-savvy, and PMs have trouble cutting scope and de-prioritizing edge cases.

If the project is quite large, I would suggest that the trio comes to leadership with a narrowed down list of options and a recommendation (with a justification why, and pros/cons/tradeoffs).

Over the course of the product development cycle, the solutions can start to stray from the original problem. For instance, teams cut a really large project into multiple releases, and end up cutting it in a way that doesn't solve the original problem. This checkpoint helps guard against shipping something that doesn't address the core problem.

In general, it's not common for projects to get shut down or undergo major changes at this stage. The backstory for why we created this process is that we used to see people go all the way to spec without doing any of the check-ins earlier. We're trying to prevent that from happening. If people have been following the process, they might not even need to go to office hours.

Ultimately, this doc is not meant to be prescriptive. It's meant to provide guidance on when you should be checking in with Growth leadership. Usually, the problem is people aren't checking in as often as they should.

If you have clear draft placeholders of these items, and finalize the actual copy and imagery later (but before delivery starts), then the grooming estimate remains unchanged.

This was also something slightly controversial. But our Engineering Manager wanted engineering leads to project manage the development portion of product lifecycle and practice communicating that outward. Our engineers had to adopt this over time (and they were great at it)!

Personally for myself and other growth leaders, we shouldn't need to be looking at every sprint (unless someone's really junior). I trust my team. Once we've approved the spec, they'll figure out how to execute on it.

Within 1 week of launch, the team should be checking for bugs, any glaring UX issues, and ensuring analytics is working / not tanking our metrics. A tiered rollout can help with this too.

We do actual results checks (1) halfway through the experiment, and (2) at the end.

My personal hot take: one pitfall I see among growth PMs is that they tend to lean on AB experiments very heavily and are running experiments that shouldn't actually be A/B experiments. I see PMs use experiments as a crutch.

If you did the full product development process, either you shouldn't have had to do that experiment, or you should have tested something that you were actually quite uncertain about. In B2B, you only have so many users and only have so many experiments that you can run in a quarter, so you can't waste them on things that are no-brainers. Running A/B experiments just so you can prove the exact impact gets in the way of moving fast.

These weekly tribe-wide meetings became an important opportunity for team members to learn from each other.

These biweekly meetings are rotating. Office hours were mandatory for PMs, designers and tech leads. Everyone else was optional. For office hours, the main point is to review what you've achieved in the latest milestone in the project lifecycle (e.g., I've done my solution explorations and want to get feedback, or I've found a new problem/opportunity area through my continuous research and want to discuss it).

All of these are essentially deliverables across the full product life cycle. This session is meant to be quite casual, where you can pull up your Figma file or doc. This got a lot of pushback from some team members because it felt like "why should I have to sign up for office hours? I should just be able to contact you directly and get an immediate review." However, this was really an opportunity to get feedback from the broader group and a great way to practice presentation skills.

Japna Sethi

I created this guide to standardize product development processes across a team with differing levels of product and growth experience. It helped drive alignment between existing and new team members, clarified how the Growth team's processes differed from Core product's, and helped establish a stronger ownership culture.

: This document describes the workflow to be used mainly for larger initiatives and feature work. 

Work involving smaller tickets can be streamlined - e.g. there will be shorter cycles, less research validation before release, 1-pagers aren't necessary.

A pet peeve of mine

The team should frame up the opportunity to gain alignment not only within the EPD (Engineering, Product, Design) team but also with (

) leadership. In this way, the Engineering team knows what our future holds in advance and leadership can help course-correct if we are misaligned on our strategy.

With this exercise, the team should write a 

which breaks down the activities required to align on the purpose of the initiative, clarifies the objectives and success metrics, identifies the right problem(s) to focus on, and describes the problem well, so that everyone is on the same page regarding successful outcomes.

Creation of the 1-pager is driven by Product with input and buy-in from Design and Engineering counterparts.

Not all ideas need 1-pagers. If an item is small in scope (e.g. a ticket), then use 

 to write up your needs. EPD squad should align on the contents of the 1-pager before presenting to Growth Tribe Leadership.

Sign up for one of the biweekly slots with Growth Tribe Leadership to present your 1-pager.

 Always remember to send a pre read in advance.

1-pager template (add New entry and the template is inside Notion as an option)

 that it requires further validation, put together a research plan. This artifact should detail what we already know about the problem, what we don't yet know (and want to), and how we will go about obtaining that information. This ensures that we plainly articulate our research goals (to control scope of discovery) and that we make use of the information we already have (instead of reinventing the wheel).

Driven by Design with assistance from Product

Determine whether or not your problem space needs more research and validation.

DACI should align on the contents of the research plan in advance of sharing with leadership

DACI to schedule review (ad-hoc) with Growth Tribe Product and Design leadership for feedback. Please send a pre-read in advance.

Research Synthesis (optional - if Step 2 was done)

A synthesis of what you learned after completing your research in Step 2 is required to (1) process the information and articulate what you actually learned, (2) share out your learnings with folks who weren't directly involved, and (3) contribute to our research repository so we don't repeat the same discoveries across the org.

Writing out your thoughts in plain English helps you to process the information, and explain it to others. Remember to provide a synthesis that someone without context can still understand. You can provide a written synthesis of your learnings in the same Research Plan document above.

Driven by Design with assistance from Product and possibly Product Marketing

Provide a written synthesis in your Research Plan

Review takeaways with your Product and Design team + leadership (can schedule this ad-hoc)

If the research is large enough, schedule a lunch 'n learn or similar session (ad-hoc) for broader team to listen in and attend, or 

share out learnings with the broader team asynchronously.

, an eng discovery is often required to help us better understand the codebase and technical constraints on design. This is an opportunity for the E+P+D squad to work together collaboratively and negotiate on what's feasible and impactful. During this process, we would plan for engineering to dedicate some sprint time to work on this discovery. 

But we expect Product and Design to work directly with Engineering during this time. This might look like several meetings of negotiation and collaboration between the members of the working team.

The expected outcome of this process is a list of solution options, with feasibility input, high level user experience, trade offs (pro's and con's), etc. with a team proposal or recommendation.

Each functional area is responsible for providing input into this process (e.g. engineering on feasibility and technical discovery, design on UI/UX). Product should ensure we are driving to the right timelines and controlling the scope.

Start creating your spec/project document (which you can fill out over time) so the team can align on it as they explore different ideas. It can help make sure we're staying true to our goal.

Before any project starts delivery, hold a spec proposal review with all of the above information consolidated in one place. 

This is time for you to explain how this solution fits back with your strategy, solves the user problems we want to solve, and get feedback from leadership on the solution proposal from the previous step, including any multi-step release strategy. 

At this point, you’ll need to finalize your hypothesis and how your experiment design and/or release strategy will answer your main question.

Ultimately, you need to argue that this is the right next step for the team and has a strong ROI.

Product Manager to drive. Ensure contributions and alignment from Design and Engineering

Sign up for one of the biweekly slots with Growth Tribe Leadership to present your Spec Proposal. Please send a pre-read in advance

Solution is ready for grooming when the concept, scope, and user flow has been agreed (and ideally validated with customers and internally), feasibility is validated, and the UI design is sufficiently solidified so that the team has a very concrete idea of what to build.

All the UI details (illustrations, copy, animation spec) might not be finalized at this point. That's perfectly fine, we'd like to allow teams to keep refining and iterating to achieve the best possible solution.

The main focus should be on any open questions related to the implementation, and to estimate the development effort.

Driven by project's Engineering owner with inputs from Product and Design

Groomed stories from the backlog are added to upcoming dev sprints based on their priority and estimated effort

Sprint checkpoints are in the middle of the sprint. We expect engineering to report out on the progress of the delivery of the initiatives.

Driven by project's Engineering owner with inputs from Product and Designs. 

Engineering is also responsible for reporting on the progress of the initiative delivery.

While experiments are running, we should ensure everyone has access to periodic updates on how it’s performing.

 This should also apply to items we've shipped as 

non-experiments (as we can still learn in production)

. When an experiment is concluding, create a results synthesis that details both the results and learnings, how that maps to the original hypothesis, and  also the next steps in connection with our overarching strategy. E.g. Did we learn something new that would make us change our strategy?

Driven by Product Manager with assistance from Analyst

Summarize results and learnings in original spec doc or link to results in spec doc

Add to Experiment Tracker. Report out results in the middle and end of the experiment runtime

Share-out results and learnings to the broader team

If Medium-Large, schedule an ad-hoc meeting with the team or sign up for office hours in order to review results and discuss next steps

Plan for GA/cleanup with engineering team

A tribe-wide meeting for each member of the team to report out on project and KR progress. We will also use this time to look ahead on the roadmap and discuss any re-prioritization, if needed.

1 hour (2x 30 mins time slots) every other Monday available for sign up with Tribe Leads to review materials from Step 1 and Step 5

These are meetings with no recurring invite in the calendar. The functional owner is responsible for scheduling these with the necessary audience. Pull in tribe leadership if you are blocked or need help making a decision. (Steps 2, 3, 4, 7)

Growth Team Product Development Processes at Productboard

Team product development processes (v2)

1) Problem & Strategy Framing

Sign up to see more