Embracing Pivots: The Vital Importance of Testing Big Changes When Prototyping

A Real-World Example From Our AI Product Communication Tool

Everyone who works in product “gets” prototyping in theory:

I.E. Build something quickly & cheaply. Test it out. Iterated based on the feedback.

However, what very few aspiring product leaders know how to do?

Build great prototypes in reality.

And I’m not talking about building in the sense of making beautiful Figma designs, or a functional no-code prototype.

I’m talking about building a prototype that actually gives us clear insight - and direction - about what we should eventually commit to building.

Specifically in this article, I’ll outline the importance of pivoting big - and the danger of testing small - when trying to validate a new product concept, as well as how to prototype effectively with real-world examples.

The Danger of Small Changes

The biggest trap Product Managers fall into when it comes to prototyping is this:

Focusing only on minor adjustments. For example, testing different colours for your main buttons, or changing the wording & positioning of different elements on the screen.

In short, focusing on small usability issues so the user isn’t blocked from getting through the core user flows.

Why a trap?

Because there is some value to minor changes! You will see incremental improvements by addressing small usability issues. The problem is that those incremental improvements rarely lead to significant innovation, as Clayton Christensen argues in The Innovator's Dilemma.

This gives us a dangerous sense of progress when, in fact, we aren’t really addressing the core risks & assumptions underpinning our prototype.

Most people get this in theory. They get that if the concept itself is not something the user seems to value, then there’s no point worrying about small usability issues.

In reality, however, it’s very hard to actually follow this principle.

Why?

The psychological struggle that comes with making a big pivot. If you’ve shared the prototype with stakeholders, you’ll worrying a change of direction makes you look weak (perceived reputational risk). If your team have spent a lot of time, you’ll feel like that time was wasted (sunk-cost bias). If you’re not seeing succeed, you’ll try to look for any progress as a justification for sticking with it (confirmation bias).

In short, it’s psychologically hard to pivot!

My team faced this challenge recently.

We started by promising “high-engaging presentations in minutes” & built our initial prototype around this promise. I’ll explain how we avoided getting stuck in the trap of small changes, however, in the next section.

The Minimal Viable Offer we validated to justify building our first prototype

The Power of A Big Pivot

To prototype effectively, we need to avoid the trap of making small changes.

Why? Because we cannot allow usability issues to distract us from what really matters:

Questioning our core assumptions.

For example, validating:

• Who is the right audience for our product?

• What value do they ultimately want from us?

• How might we deliver that value in a unique way?

• Can we actually deliver that solution in practice?

For example, Slack’s founding team initially starting as a gaming company called Tiny Speck. After realising that the games they were working on just weren’t that good - neither valued by the target customer, nor profitable - they pivoted. They pivoted, instead, to building out a team communication platform they had developed for internal use. That platform now has 42.7m daily users.

Or take Twitter.

Twitter started as Odeo, a podcast platform, before pivoting into a microblogging site (Hatching Twitter).

They - like many other successful companies - pivoted on their core assumptions (about audience, value & the way they would deliver value) & were successful as a result.

But it would have been easy to not do that. To keep pushing. To just try “one more iteration" of that video game. But that “one more iteration” would eventually have killed the business.

Our Example: A Big Pivot

Once my team validated that our audience of Product Managers seemed to value our offer of “building high-engaging presentations in minutes”, we built & tested our first prototype. Here are some wireframes:

Prototype v1: Build engaging presentations in minutes

The problem?

The value of the product was clear to the Product Managers we tested with (essentially, define a presentation objective → AI then generates an outline → edit outline → edit slides).

However, we hadn’t differentiated our product enough from AI-driven competitors like Tome or Gamma, which were already doing a great job of delivering AI-generated presentations.

So for v2, we went back to the drawing board & focused on two key things:

1. Tome has done an amazing job of removing friction from generating a presentation. We therefore wanted to copy some of their core design decisions as a base for our product

2. We wanted to more strongly differentiate our offer & solution with a bigger emphasis on storytelling i.e. crafting a great narrative before working on the slides themselves

Here was the general concept:

v2: Build engaging stories in minutes (copying some of Tome’s core design decisions)

But, when we tested this concept, it just felt like a worse version of Tome. Poor functionality, a lack of clarity for users around how the narrative underpinning each presentation was built &, even a little confusing as a concept.

Maybe if we’d committed months to code it - rather than test a Figma high-fidelity prototype - we might have seen better results.

However, both our product sense & user feedback was telling us:

This is the wrong concept.

So we decided to pivot.

How to Pivot Your Prototype

Like with our own example, when deciding whether to pivot or not, it’s a messy decision.

You will never get conclusive data to tell you that it is the right or wrong decision.

For example, we made 3-4 small iterative changes on our presentation concept before deciding to pivoting on the solution entirely.

Eric Ries, author of The Lean Startup, would argue that we have to rigorously test our assumptions when deciding when to “pivot or persevere”. Unfortunately, the natural conclusion to this argument is that we would have to eventually build the real thing (i.e. a fully functional, coded product) that might take months to build.

I agree that we should be rigorous - & the Product-Market Fit Engine is a great model for testing a prototype rigorously - but, in my experience, the decision comes down to gut instinct & user feedback, as well as a good cold, objective look at the situation.

It therefore comes down to a combination of gut instinct & any user data suggesting this may not be a compelling product for them, as Eric Ries argues in The Lean Startup.

In practice, the most effective way to decide on a pivot is to come back to your core assumptions:

• Does the target market seem to value the proposed solution? If you’ve developed a fully-functional product, are they using it?

• If not, is that because we are delivering the wrong value for them? Or is it that we just aren’t actually delivering on what we promised them?

• And if we’re not delivering, is that because the solution we’ve proposed is too hard to deliver (feasibility)? Or that it’s just the wrong vehicle to deliver that value (viability)? Or maybe we just made really poor design decisions that mean they can’t even get to the value (usability)?

Our Example: Questioning Core Assumptions

In our example, we revisited our core assumptions & concluded the following:

✅ Not to pivot on the target market. Product Managers clearly saw value in building “presentations in minutes” i.e. saving themselves lots of time. This was also supported by survey data we had gathered during the Beta

⛔️ To pivot on our offer. Because Tome & Gamma do such a great job at automating presentation created, we wanted to focus on not just saving our audience time, but double down on helping them tell a compelling story. Great that Tome helps you build a beautiful presentation, but not that important for a Product Manager who needs to convince stakeholders through compelling stories.

⛔️ To pivot on our solution. Rather than creating “just another presentation tool”, we decided to question the very category (a topic I’ll dive into in next week’s article). That meant questioning the very conventions underpinning “presentations”. Why, for example, are presentations done live? Why not asynchronously? And why do we have only 1 version a presentation for all stakeholders? Why does that make sense when, for example, a CFO wants to focus on financial data, and a CEO on a general overview?

From these conclusions, we decided on the following concept:

To “go beyond boring, time-consuming presentations” (the old category) & focus on something new:

Building shareable Product Stories.

v5: Creating a new category by going beyond live presentations. A focus on a compelling, AI-generated storyline. But a storyline customised for each stakeholder & presented asynchronously through a simple share link

Conclusion

When prototyping, it’s very easy to keep iterating on small things. You’ll feel like you’re making progress & you’ll see some small improvements. Just remember:

This is a trap.

If you aren’t seeing strong signal that your core assumptions are correct, you probably need to pivot - and pivot big - on your audience and/or offering and/or the specific way you deliver (solution concept).

If you do, you might end up like Slack or Twitter: Far from where you started, but extremely successful.

If not, you might iterate small just one too many times - and run out of funding.

So embrace a pivot-first mentality with any new product you are developing — even for existing products that haven’t quite achieved Product-Market Fit!