Our goal with product management at Gatsby is to create an ongoing and iterative product discovery and development process that allows us to ship customer value quickly and with confidence in our product–market fit. There are a lot of ways to break down product development and management.
The first is “waterfall” development where information is generated at the “top” of the company and then slowly (or quickly) trickles down to the rest of the organization for execution.
Alternatively, there is the “agile” approach that focuses on small teams making fast decisions and moving quickly.
At Gatsby, we want to ensure we’re aligned around business objectives set at the company level, while also bringing research, design, and engineering into the product development process early so that everyone has the context they need to succeed. We also want to encourage everyone at Gatsby to experiment, make mistakes, and tinker with ideas.
Ultimately the product manager is responsible for “evaluating opportunities and determining what gets built and delivered to customers” (Marty Cagan, Inspired: How to Create Tech Product Customers Love).
The best way to do that is by creating a prioritized backlog of ideas that are worth building, prioritizing that work, and collecting customer feedback for action.
This then becomes a cycle that we can rely on to constantly feed us with new ideas. But this is where it gets more complicated.
There are a few ways product managers can start generating ideas for their backlog. We’re not going to talk about the specific process in this post, but rather the model we want to follow to help us generate a backlog.
Discovery research is focused on talking with current or past customers about their experiences with a product or workflow that your product has. This type of research helps you understand the needs of the customer, get an understanding of what’s working for them now, and get a list of problems they’re having.
The product manager needs to have enough context of the landscape to decide which of these problems are critical for solving and work with the team to create acceptance criteria that solves the problems we’re trying to address.
Many times, it might be helpful to have a visual concept to show stakeholders to get them interested and bought into larger pieces of work. This can be a presentation deck with market research interviews, relevant data, or customer interviews.
At Gatsby, we often use a type of Jobs to Be Done discovery work. We talk with people who we’ve identified as our potential customer base to get a good understanding of their day-to-day needs, pain points, and workflows. By doing that, we’re able to understand common patterns across companies and large areas of frustration that we can address with our products.
Prototyping can be done by product managers, designers, engineering, or anyone with context on the problem we’re trying to solve and outcome we’re trying to achieve. The goal of prototyping is to show someone how to solve a complex problem, rather than trying to only explain it to them.
The product manager is responsible for making it clear that there is prioritized work available for technical feasibility research or prototyping when initial discovery shows that an idea is worth pursuing. It’s important to do this as early as possible so that engineering is involved in the ideation. This helps the team make better decisions about whether or not the feature or product impact is worth the cost to create. Doing this research early helps avoid wasted time and money pursuing ideas that aren’t actually reasonable to build.
Feasibility research helps you decide if it’s possible to make and what the cost will be in terms of time and resourcing.
Both feasibility research and prototyping are used internally to create context and help with understanding outcomes, risks, and needs for upcoming work.
Recently we’ve used prototyping with our current build updates. By prototyping the functionality on a small scale, we can use the updated build process internally and identify any immediate issues or errors much more quickly.
A proof of concept is closer to a high-fidelity, workable prototype that is meant to be customer-facing. It works within your product, looks like it belongs there, and collects data. A workable proof of concept helps reduce the time to ship because you can try it out with reference customers or do a small rollout to a portion of your customer base.
We initially did proof of concept work with Gatsby Preview in its alpha phase. The functionality existed, and we were sharing it with people, but it was a small group of testers who helped us find what worked well and what needed to improve so that we could continue making the product better.
At Gatsby, we wanted to make sure we had a way to look at work from a macro to micro level. Doing this made sure we had higher visibility for our work.
We use Wardley mapping to think through the strategic value of a product and give us a high level picture of where we want to go. Wardley maps are like topographical maps for your business or product. You’re able to see the current landscape and map out where your product currently is, as well as plot how it will evolve over time as the business and product landscape changes.
We’ve had working sessions where we will complete Wardley maps as a team around product ideas, or existing products that we are interested in evolving. Wardley maps help us create shared context with our product, design, and engineering teams so that we understand where we currently are and where we’re trying to go with the product.
Our Principal Product Manager, Preston So introduced us to intent mapping as a way to set priorities and dependencies for major pieces of product work over the next 3 - 6 months. It’s a way to let all the teams have one source of truth for what we want to focus on in the medium-term.
Acceptance criteria listed in the intent maps helps explain what we are going to build and why. We don’t create anything without a reason, and always bring the team in to collaborate on acceptance criteria.
Objectives and Key Results (OKRs) are specific metrics or outcomes we want to see within the next 1 - 2 quarters. We use OKRs to stay focused on what we’re trying to achieve in the short term. Our OKRs are typically very metric driven, so that it’s easy to know whether or not we’ve achieved our goal. You can read more about OKRs at Gatsby here.
One of the additional benefits of creating proof of concept work is that you’ll have something to share with reference customers as you figure out the best way to solve your biggest customer problems. Reference customers are current paying customers that have agreed to try out proofs of concept, prototypes, or alpha products to help us decide if what we’re creating has product-market fit and adds value.
It’s up to the product manager to have ongoing interviews with reference customers, and to understand whether or not the proof of concept adds value for them.
At Gatsby, we get product feedback from lots of great sources: usability research, data analysis, customer support, pre-customer calls, and customer calls. We’re always excited to talk with people that are using or interested in using Gatsby, and doing this consistently has helped us validate ideas and surfaced new challenges to tackle.
Gatsby is growing fast and we have a few main Key Progress Indicators (KPIs) that we want to stay focused on in the next year. Product management will probably shift and grow as Gatsby shifts and grows. But even as things change, we will always want to focus on reaching out to customers, understanding important problems, and providing solutions for those problems. Our focus should always be to add value and excitement for our current (and future) Gatsby customers and community members.