Photo by Michał Grosicki on Unsplash

Over the past year I’ve become increasingly aware of a fundamental divide in the prevailing wisdom on how good products are built. I’m not talking about waterfall vs. post-waterfall methods. I’m also not talking about the differences between specific methods like Agile and Lean. I’m talking about different philosophies on the best way to build products in an already post-waterfall world.

These differences have been apparent for a while, but they came into stark focus for me over the past week, as I finished reading two books in quick succession: Getting Real by Basecamp and Inspired (2nd ed.) by Marty Cagan. Both books are interesting and worth reading by themselves, but even more so when you read them right after another.

Basecamp and Marty agree on the biggest challenges in building good products, but diverge quite often on how they believe teams should deal with those challenges. Let me provide a couple of examples.

The same, but different

Both books are adamant that value (defined as whether someone will use/buy your product) needs to be validated as early and as cheaply as possible, and that the old ways of doing things are expensive and wasteful. Basecamp says you do this by “racing to running software” and making sure that it’s cheap to make changes:

It’s ok to do less, skip details, and take shortcuts in your process if it’ll lead to running software faster. Once you’re there, you’ll be rewarded with a significantly more accurate perspective on how to proceed. Stories, wireframes, even HTML mockups, are just approximations. Running software is real. […]

With real, running software everyone gets closer to true understanding and agreement. You avoid heated arguments over sketches and paragraphs that wind up turning out not to matter anyway. You realize that parts you thought were trivial are actually quite crucial.

And earlier:

Change is your best friend. The more expensive it is to make a change, the less likely you’ll make it. And if your competitors can change faster than you, you’re at a huge disadvantage. If change gets too expensive, you’re dead.

On the other hand, Marty believes in building prototypes really fast, and testing those with real customers before you commit to code:

One of the most common traps in product is to believe that we can anticipate our customer’s actual response to our products. We might be basing that on actual customer research or on our own experiences, but in any case, we know today that we must validate our actual ideas on real users and customers. We need to do this before we spend the time and expense to build an actual product, not after.

And later, on prototypes:

Product discovery [coming up with a validated product backlog] involves running a series of quick experiments, and to do these experiments quickly and inexpensively, we use prototypes rather than products.

On the topic of “functional specs”, both books agree that writing long specs filled with “requirements” is a terrible way to build software. I don’t think any of us disagrees with that. But again, they diverge on the best alternative. From Basecamp:

So what should you do in place of a spec? Go with a briefer alternative that moves you toward something real.

Write a one page story about what the app needs to do. Use plain language and make it quick. If it takes more than a page to explain it, it’s too complex, The process shouldn’t take more than a day.

Then begin building the interface — the interface will be the alternative to the functional spec. Draw some quick and simple paper sketches. Then start coding it into HTML. Unlike paragraphs of text that are open to alternate interpretations, interface designs are common ground that everyone can agree on.

Marty favors a technique called the Opportunity Assessment for the vast majority of projects:

The idea is to answer four key questions about the discovery work you are about to undertake:

1. What business objective is this work intended to address? (Objective)
2. How will we know if we’ve succeeded? (Key results)
3. What problem will this solve for our customers? (Customer problem)
4. What type of customer are we focused on? (Target market)

[…] You need to ensure that every member of your product team knows and understands the answers to these four questions before you jump into your product discovery work.

Many ways to skin a cat

To summarize this another way: most people in this post-waterfall world agree that the biggest reason why software projects fail is that various risks are assessed too late, which ends up being too costly for the business to survive. Most even agree on the core principles to follow to fix this: tackle risk as early and as cheaply as possible. Where we are seeing the divide is in how this should be done.

One perspective is what we can call the prototyping movement (I’m deliberately staying away from naming specific methodologies). The goal is to align around business objectives and build functional prototypes to meet those objectives as quickly as possible, and test those with real users before engineering gets involved.

The other perspective, the real software movement, says that even that takes too long, and that nothing can replace the feedback you get from working software in production — as long as you’re able to make changes very quickly.

So which is it?

In our search for easy answers and silver bullets, the obvious next question here is, “ok, so who’s right?” But I think good product managers eschew such easy answers. Good product managers are always learning about different perspectives, but they have to learn through an added dimension—the lens of their own product and culture.

So for me, the real takeaway from these books hasn’t been the prescribed solutions — although those are certainly helpful as idea starters. The real takeaway has been all the roadblocks to good product development that I noted down as I was reading. The different kinds of risk we need to validate. The constraints we tend to miss when we brainstorm and plan. The heavy processes that do nothing more than slow teams down and make them unhappy. How to address those challenges in a particular culture is where the true art of modern product management lies, and what makes the job itself so difficult to pin down, define, and get good at.

I’ve learned a great deal about product, culture, and teams this year. But no lesson has been more valuable than this: the challenges to building good products are universal, but the solutions are not, and the biggest value I can add to the team is to work with them to figure out the best way for us, in our context to address these challenges in a way that ensures the team is happy and productive, and our customers love our products.

I’m guess if I have to make a New Year’s Resolution, getting better at this would be it.