Shape shape shape

How we think about product

Hi all —

Breaking news: Software is difficult.

One thing I’ve realized is that there are a million ways to configure a particular feature. Some versions of a feature take a 10-person development team years; others take a single developer a few hours.

Layer atop tons of other variables that you need to consider when building a new feature:

• Is this the most important thing we could be doing right now?

• Is this particular solution intuitive for our users?

• Does this feature actually solve the underlying problem or capture the opportunity?

• Could there be a more elegant solution that gives us more flexibility in the future?

• Can we even support this?

• How do we describe this to customers?

• Could we just NOT do this?

• What are we not considering?

Think too much about this stuff and you’re paralyzed. Think too little about it and you’re probably shooting your future self in the foot.

And this is why managing the software product development process is one of the most difficult jobs in tech — it has a nonlinear impact on the business, and the most nonlinear part of product development (“shaping”) is more art than science.

So, shaping: Inspired by the book “Shape Up” (free here), Shaping is how we get from an idea to a buildable concept.

You may consider this “discovery” in dual-track agile, or just plain UX.

In our company, we have one person responsible for shaping each development project. They are ultimately responsible for making sure engineering builds the right solution.

We don’t have a formal process to this quite yet, but these seem to be the steps:

1. Investigating the problem or opportunity, figuring out what’s at the core of it

2. Iterating on tons of different configurations of the solution to come up with the best hypothesis

3. Getting feedback from customers, sales, customer success, design, and engineering to narrow the solution space

4. Randomly coming up with new ideas, realizing that the original idea was dumb, deleting the entire shaping document, starting over

5. Communicating the final version of a shippable solution

It helps a small engineering team focus their time productively on the highest-possible-leverage items. We’re giving them easy layups instead of half-court threes.

Ultimately, this makes sure that:

• We actually know what’s at the core of what we’re trying to accomplish with each new feature.

  • Why? Because in general, the “business logic” behind product backlogs is squishy and poorly defined. When this is the case, no amount of downstream excellence matters.

• We’ve spent time figuring out the best potential configuration of the solution, including deeply thinking about the many “what ifs” and “what abouts.”

  • Why? Because (1) doing this well gives our engineers nonlinear impact, and (2) engineers find it annoying to get thrown “solutions” that clearly lack deep thought.

• We’ve pulled in a bunch of people with different perspectives to provide inspiration for us to make the right product decision.

  • Why? Because there are configurations of products that take longer to build and don’t NAIL the value for customers. As smart as each person who “shapes” a project is, they will never nail this in the first go-around.

Curious if any of you have nailed this? Any particularly effective product processes that help you focus on the most important things + ship them in the most effective ways?