Skip to main content

Marisa Morby

Product manager solving problems with research and process. Aspiring gardener and baker of delicious treats.

7 min read · April 8th 2019

How we think about product at Gatsby

As a company grows, it will eventually start offering products or services to the community it’s trying to serve. It’s an exciting time filled with near constant changes. At Gatsby, we realized that this meant we needed to have a better understanding and core philosophy around the products we create.

So, we blocked out our schedules and met for 3 days over Zoom, with people calling in from different parts of the USA, Germany, and England to read, workshop, and talk about product.

On the call, we read excerpts from Marty Cagan’s Inspired: How to Create Tech Products Customers Love. We’re using a lot of his advice to help create a product organization and product management framework at Gatsby.

What is a product and what are Gatsby products?

After a lot of back and forth, talking through examples, and working through questions, we landed on what we think of as “a product” at Gatsby.

A product is an individual thing (software, hardware, etc.) that facilitates stable customer behaviors and is scalable.

Additionally, a product must add value in order for a customer to continually use it. At Gatsby, we believe that we add value by solving real and impactful customer problems for individuals and teams in the web development community.

What is our product organization?

A product organization is the group of people responsible for thinking about what we offer our customers and why. Our product organization, or product org for short, currently consists of a group of product managers, designers, and UX researchers.

The goal of the product org is to understand the pain points of our customers, create relevant personas, and do the necessary research, discovery, and prototyping so that we can provide solutions they find valuable.

What does the product organization do?

Since we are putting together a group focused on product, we also want to have outcomes that keep us on track. An outcome measures the level of performance or achievement that occurred based on the thing we created and measured. That means that we can have outcomes based around company goals, around products, or even around specific features.

Identifying the outcomes we want for persona and business problems

We focus all of our conversations around problems at Gatsby. We want to discover, identify, and map out problems that exist both for the business and for our customers and community. By identifying how impactful and prevalent the problems are, we can start deciding if and when we want to tackle solving them.

Driving alignment with company Objectives and Key Results (OKRs)

Identifying and writing down these problems also helps us write our objectives and key results because the objectives are created to list what we want to do based on the problem we are trying to solve, and the key results show how we will measure that it’s been done.

Each team in Gatsby has objectives and key results that they are responsible for hitting.

The product organization is responsible for making sure our key results are set and that any dependencies on other teams are clear, so they can successfully achieve their key results as well.

Creating an outcome-based roadmap that gives the company a sense of where we are with product development or features

As we learn more about our community and our customers through research, discovery, and metrics, we will create a roadmap that shows what outcomes we want to provide for people. This is different from a traditional roadmap because we won’t be focusing on features, but rather on the problems we’ve seen and the outcome that will show we’ve solved the problem.

Giving internal stakeholders high integrity commitments

There is always some measure of conflict between sales, marketing, engineering, and product. Each group has a goal that it’s trying to accomplish. These goals should create a checks and balances system that keeps teams researching, prototyping, building, and communicating with customers. As an example, engineering wants to build the best possible product from a technical standpoint. Product wants to create value for the users. Sales wants to sell as much of the product as possible to the broadest audience on the shortest timeline. Marketing wants exciting improvements that generate buzz and create opportunities for publicity.

All of these goals are important, and create a necessary tension that forces us to make collaborate and make decisions in order to keep moving forward.

As we create and improve upon our products, managing that conflict works best when expectations are properly set.

Because we believe that setting timelines creates an arbitrary end date, we instead aim to create very actionable and small scopes of work that we can tie to a high integrity commitment.

A high integrity commitment is a commitment that we can make to internal stakeholders about when an iteration, product, or feature will be complete.

Instead of giving this outright, we instead look at the problem we’re trying to solve, do prototyping and feasibility testing, and create a scope. After taking the time to understand what the problem is, how we can solve it, and how much time it will take us to create the solution, we’re able to give a much better estimate for highly awaited products or features.

We won’t give these high-integrity commitments for everything, but if we know that sales or marketing is waiting on us to move forward, then we have a reasonable timeframe to talk about that’s based in reality.

This will also help us set better expectations with our community, and make our plans more clear.

How does the product organization fit in with the rest of the company?

The product org is the group of people within Gatsby responsible for identifying product opportunities, doing customer discovery, usability research, and design. That means the product organization needs to understand the needs of the customer as well as the needs of the company in order to make sure that both are successful.

What processes do we want to focus on?

Since we are a growing startup, any process we write here will probably change a bit in the next few months. What won’t change is how we think about product and what we communicate across the company. That means a few key areas will be really important for us to focus on.

How we communicate product ideas

We are a remote company, so it’s very important that we have common knowledge and understanding. Introducing a communication strategy that is more agile and allows for open communication is one way we will tackle this.

That means that product initiatives will collaborate with research, engineering, and design right from the beginning to make sure we have shared context where it counts most.

We’ll also focus on product discovery, rapid prototyping, and validation so that we can prioritize effectively. We’ll make sure to do MVPs, described as Minimum Viable Prototypes in Marty Cagan’s book Inspired. This is really a difference in functionality and fidelity. A product will typically have many features at high fidelity, while a prototype will have limited functionality at a lower fidelity.

We typically think of MVPs and Minimum Viable Products, but that often means that we are creating something that’s very well thought out and crafted before we check to make sure it’s something people want or something we should spend our time doing. By focusing on research, discovery, and prototyping we keep the focus on our end users and retain the ability to rapidly test potential solutions.

How we focus on personas

Because we want to stay user-focused, we will also be doing discovery and usability research against specific personas that are important to Gatsby. As we learn more about our audience, we’ll get a better understanding of current personas and start to see new personas that we should define. How we prioritize Since we’ll be doing a lot of discovery, usability research, and prototyping, that means we’ll have quite a bit of prioritization to do.

We’ll prioritize based on OKRs we talked about before. Objectives show what we want to accomplish and key results show how we’ll measure that we’ve accomplished it.

The business vision and objective is set at the company level, and the business results are set by the individual teams. This means that teams will have the autonomy to hit the business objective in the best way they see fit.

How we put it all together

Outcome-based roadmaps

Once we understand the ideas we want to prioritize, the objectives we’re trying to hit, and the results we’ll use to measure those outcomes, we can put together a roadmap that shows where we want to focus.

Typical roadmaps are difficult to use because they don’t communicate information in a way that addresses everyone’s needs.

To make sure that we don’t fall into this trap, we will do outcome-based roadmaps. Our roadmap will include:

  • our business vision
  • our objectives
  • our business results

This will help us focus our roadmaps on business problems we’re trying to solve, rather than a general feature that we’re not sure is important.

Where will all of this information live?

This is obviously a lot of information to gather and we want to be sure we capture the important parts and provide a reference and source of truth for the team to work from.

Product Requirement Documents

Specifically for product, we create Product Requirement Documents (PRDs) that will explain what we want to do and why. They will include information that we need to scope out the product or feature, and also include the evidence that shows why we should do this. Because we want to make sure our decisions are based on actual problems, research, and data we always include that in the PRDs as justification.

RFCs

At Gatsby, we also create Request for Comment (RFC) docs. These are detailed proposals that explain what’s changing in the codebase and why. It’s basically a technical proposal for a spec change. How do PRDs relate to RFCs? PRDs lay out what the product, product feature, or product change is and why we are doing it. RFCs relate to what is changing in the codebase and why.

Rolling with changes

We’re sure that processes and needs will change as we scale and grow. But how we think about product within Gatsby will help us make decisions on whether the processes we currently have are helping us, and give us a foundation for new processes in the future.

We need your help to be better

You may be wondering why we’re telling you all of this. One of our company values is to work in the open. And that means letting our community know what our plans are, how we’re organizing our work, and how you can help us.

This is our initial effort to let you know how we think about product at Gatsby and what it means to us.

We’d love your help in hearing what Gatsby means to you. The first step in all of this is talking with the community and continuing to learn from you.

Tell us about your experience

One of the best ways you can help is by talking to us about how you use Gatsby now, what works for you, and what problems you have. Getting the opportunity to understand your problems helps us create better solutions for you!

If you’d like to participate in our research efforts, @shannonbux is always looking for research participants. Sign up to get notified about upcoming research studies.

Tagged with gatsby-incView all Tags

Enjoyed this post? Receive the next one in your inbox!

Docs
Tutorials
Plugins
Blog
Showcase