From Working Backwards to Feature Docs.

During the last few months at CARTO we have been focusing on designing and implementing processes to face some of the challenges of a product team in a fast-growing organization. Since growing means learning this post is about something we've learnt and something we actively use in our day to day work.

The mix of acquiring more clients getting bigger contracts hiring new executives and opening offices in new locations was making the product team a bit less impactful in the organization. Even if we kept working with the same intensity (or even more) features fixes and enhancements were not impacting the rest of the organization in the same way they used to. When we were ~50 everything we did in product was rapidly announced understood internally and sold externally but this was because everything was almost done by the same people by that time we "were" all Product Managers.

Nowadays in an organization with +100 people we have adopted some specific methods to reverse that trend.

When thinking about how our process should look like we decided to focus on:

• Ensuring product market-fit.
• Maximizing the impact within the organization of every new relevant thing in any of our products.
• Easing the hand off process within the different departments.

Working Backwards

There is a methodology called working backwards which became popular a few years ago and that was widely used at Amazon. In a nutshell it consists on trying to work backwards from the customer rather than starting with an idea for a product and trying to bolt customers onto it.

When "working backwards" new initiatives the Product Manager typically starts by writing an internal document similar to a press release announcing the finished product. The target audience for the press release is the new/updated product's customers which can be retail customers or internal users of a tool or technology. Internal press releases are centered around the customer problem how current solutions (internal or external) fail and how the new product will blow away existing solutions.

Once the project moves into development the press release can be used as a touchstone; a guiding light. The product team can ask themselves "Are we building what is in the press release?". This keeps product development focused on achieving the customer benefits while the rest of the teams can understand the whole picture and start preparing their action points.

In working backwards methodology we saw a great starting point for improving the issues we were identifying.

From Working Backwards to Feature Docs

In our case we've taken the principles of working backwards and modified them a bit to adapt to the company we are now and the way we operate.

Whenever we start thinking about a new development Product Managers start by writing what we call a Feature Doc. That document will serve as a guide for Product Designers and Developers and will enable Marketing and Sales to start contributing to the document with specific content about how to communicate and sell what we are doing before we even write a line of code.

Here's an example outline for the Feature Doc:

• Heading: Name the product in a way the reader (i.e. your target customers sales reps etc…) will understand.
• Summary: Give context and write a summary of the feature and the benefit. Assume the reader will not read anything else so make this paragraph good.
• One sentence explanation: Summarize everything in one or two sentences that can be used for slides tweets or other documents.
• Solution: Describe how your product solves the problem and describe in precise detail the customer experience for the different things a customer might do with the product. We normally link to mockups and interactive prototypes for this.
• Proposed Roadmap: Describe the different versions of the feature (if any) and the scope of each of them. Define also when the feature will be available to some or all users. We focus on developing stuff in a way that ensures the MVP will be ready fairly soon in production – under feature flags –.
• Customer Quote: Provide a quote from a hypothetical customer that describes how they experienced the benefit.
• Key messages: Product Managers and Marketing work together on a list of key messages for communications.
• How to sell: Describe pricing details as well as the type of users (if not all) that will benefit from this.

After distributing the Feature Doc the different teams start to work on their own action points. In the Product team for example this gets translated to a milestone and a set of GitHub issues while in the sales team it might mean adding new information to the battlecards or the ratecard.

Is this working at all?

As someone that works in the product team I can say that Feature Docs have improved a lot the way we work communicate and sell things internally. Working in the document helps us do research diverge and converge when it's still easy and quick and reduce the amount of changes we have to do once the development is in progress. On the other hand Feature Docs are a good way of being sure that every stakeholder is aligned with what the feature is about how it should be communicated and how it will be sold.

Feature Docs have quickly become the minimum viable documentation we need to start working on new things.