Rapid Prototyping & Product Management

Tom Chi shares 5 lessons on rapidly prototyping

1. Create a culture of learning

Most product organisations struggle not because of a lack of technique and tools but because they suffer from the culture of right and wrong, where success is rewarded and failure is punished. This is intrinsically diminishing, as you never focus on learning what made anything successful or unsuccessful.

Tom instead emphasizes a culture of learning – where even if you’re wildly successful but only learn one thing, it’s less valuable and praised than if you’re wildly unsuccessful but bring back several key learnings from that experience. A key learning is an embodied or observed experience that materially changes your path forward, instead of getting stuck in the debate of right and wrong with conjecture.

Sadly we still often get involved in guess-a-thons, endless meetings where we discuss and argue product decisions using guesswork and conjecture, but by rapidly prototyping actual experiences we can shortcut all of that with real insight from real experiences.

2. Staying in the Medium

Imagine being an artist, whose medium is oil paint, and instead of just putting brush to canvas having to write a slide deck, take it to a meeting, get some stakeholders on board, formalise it into a specification, and then shepherd it through the development process. Think how hard it is going to be to create a masterpiece if that’s the process you have to follow? As a purely practical matter you’re spending almost no time in your medium – the paint – and all of your time in spec reviews, meetings, etc.

So if staying in the medium allows you to dramatically see more of what’s happening and bring forward a masterpiece, then you have to ask yourself what the medium is of what you do.

The funny thing is most people who build software and hardware think their medium is the code or the pixels. But for everyone who builds products, the real medium is human behaviour in the real world, and your purpose should be to be in that medium all the time – to see that human behaviour modified by what you build.

Now product managers have a really interesting medium, because we spend no time in code or pixels, but alot of time managing uncertainty, which makes that our medium. But hopefully through the process of wrangling uncertainty something beautiful comes out.

3. Optimize Loop Length

Loop length is the amount of time between asserting a new conjecture and observing the actuals from that conjecture. Most of us have a loop length measured in years or months. Even if you’re releasing every day through continuous releases, but not learning anything from actuals from customers, that loop is open and it needs to be closed.

Tom’s teams work with loop lengths measured in days. They create a cadence by building in non-negotiable customer feedback time twice a week, where they test whatever they have built so far in order to capture the actuals and key learnings. They will even have the development team on speaker phone during the testing to get the loop length on small usability issues down to 15 minutes. In addition to these immediate optimisation lessons, they’re looking for “eyes light up” moments where the customer responds to your product.

4. Find “Eyes Light Up” moments aka “Magic Moments”

These beautiful moments with your customer are actually what your product is all about. Your product is not the search box, the ad algorithm, your user records – it is this magic moment, and your task is to get out of the way of the magic moment or to amplify the magic moment.

As an example Uber has two magic moments 1) press a button and car shows up for you, and 2) when you leave the car without paying. That’s why they’re worth $50 billion. The magic moment at Uber is not what the login flow was like!

Your product is not the world, your product gets used in the world.

5. Designing for adaptability vs. designing for scale

Finally, the key to be able to prototype so quickly and shorten the loop length so much is to focus on the culture of development. Most of the time development is focused on stability and scalability, but they can also design for adaptability. So start any new product with a design for adaptability, with the understanding that most of this code will be thrown away. This allows you to decide what to do fast, and then focus on designing how to do it at scale.