Solving the first-step problem

The problem

People were getting stuck on the very first choice: which playbook to start with. Each playbook takes hours, like running customer interviews or testing a price. Picking the wrong one wastes that time, so people hesitated, guessed, or gave up.

For Strategyzer, this was the costliest place to lose people. If nobody starts a playbook, nobody gets value from the product, and every number that matters, from sign-up to renewal, depends on that first step.

How people found their first playbook depended on what kind of customer they were.

123

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Most popular, not most relevant. The first picks are what other people chose, not what fits your problem.
2. 2A long description for every playbook. You have to read and make sense of each one before you can tell if it’s for you.
3. 3Then the whole library. Below that, every playbook we have. Search and filters only help if you already know what to look for.

The numbers showed the scale: about 43% of new customers never started a project.

Interviews showed why. I spoke to eight customers, plus our customer success and coaching teams.

If our coaches found it hard, the problem wasn’t our customers. It was the product. And it wasn’t only new customers: returning ones faced the same choice every time they started something new.

The first bet

Customers were asking for AI, so we started there. The first idea was ambitious: Strattie AI, an assistant across the whole platform, like having a Strategyzer coach beside you at every step. I designed it and built a working prototype with Claude, using FondUI, our design system.

• A coach you could chat with. Available on every page and aware of your project. It helped people shape ideas, brainstorm and challenge their own thinking.
• Help on the canvas. It could summarise people’s work, point to the evidence behind it, check their ideas, draft sticky notes and flag what was missing.
• Recommending playbooks was one of its many jobs, not the whole product.

Building it for real taught us three things a static design would have hidden:

• The value was in the questions. A good coach asks two or three questions before recommending anything. In an open chat, the assistant often answered before it had asked them.
• Doing it well was a much bigger job than it looked. Vague requests, a changing library and knowing when to say “I don’t know” were more than our small team could take on at the time.
• Chatting isn’t the right tool for where do I start? People came to us because they couldn’t put their problem into words. A chat box asks them to do exactly that.

The reframe

Engineering couldn’t build the full assistant in the time frame we needed. The team’s first instinct, a fair one, was to build a smaller version of it.

How I made the case

I needed to convince our CEO and our Head of Product, who was keen on the assistant. On a call, I showed them the working prototype and my research. Every group we spoke to had the same need: help choosing where to start.

It was a trade-off, and I made it knowingly.

Designing the Recommender

The form

1. A small panel in the corner. I tried three shapes. A pop-up in the middle of the screen covered the library people were choosing from. A tall side panel looked like a chat that wasn’t there. A small panel in the corner won: easy to find, and the page stays usable behind it.

2. Answers shrink as you go. Borrowed from Asana’s AI menu: once you pick an answer, it shrinks to a short message and the next question appears below. The panel stays short and easy to read.

3. A tool, not a tutorial. I removed anything that promised more than it did: a chat box, a history list and expandable sections. I also dropped the tour-style version I first explored, with its progress bar and “three easy steps”, because this is a tool people return to whenever they’re stuck, not a one-time tour.

Explored · Tour-style

Shipped · Tool

The logic

4. The questions come from research, not guesswork. Behind the questions is a map I built in two days from how customers described their situations: 5 problem areas, 17 goals and 45 paths, leading to 19 playbooks. Because it’s written down, not generated by AI, we can trust it and fix it when it’s wrong.

5. Questions anyone can answer. Question one asks what you’re working on in everyday words, so founders new to Strategyzer can answer it. Question three, where are you now?, only appears when it changes the answer, so people with work already done can skip ahead.

Question 1 Question 2 Question 3 Recommendation

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1In the corner, not a pop-up. The page stays usable behind it, and it stays out of the way until you need it.
2. 2“Under a minute”. Says how long it takes up front, so starting feels safe.
3. 3Everyday words, not method names. People pick what they want to do, not which tool to use.
4. 4“Something else”. Anything that doesn’t fit, in their own words.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Your answer, kept short. Once picked, it shrinks to a short message, so the panel stays easy to read.
2. 2Goals, still in plain language. Question two narrows the problem to what you want to achieve, like mapping or assessing your business model.
3. 3The panel stays the same size. When there are more options than fit, the list scrolls inside it.
4. 4“Something else”, at every step. There is always a way out in your own words.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1Your answers stay in view. Each pick stays as a short message you can go back and edit.
2. 2Only asked when it matters. “Where are you now?” appears only where it changes the recommendation.
3. 3About progress, not expertise. The options describe work you have already done, so people further along can skip ahead.
4. 4The panel doesn’t shrink. Fewer options leave space at the bottom instead.

1234

⤢ Full size

Hover a decision to see it in the designTap a decision to see it in the design

1. 1One clear first step. A single best fit, so nobody has to choose between equals.
2. 2You can switch at any point. It is a place to start, not a commitment.
3. 3Straight to the work. One click takes you to the playbook.
4. 4What else it considered. Close alternatives are shown, not hidden, so the pick is easy to trust.

6. Small details that build trust.

The panel stays the same size. Early versions grew and shrank with every answer, which felt jumpy. Now it keeps one height and the content scrolls inside.

You can change an answer without starting over. Click any earlier answer to edit it.

AI for everything else. If none of the options fit, people can pick “Something else” and type their situation. AI reads it and finds the closest playbooks from the same map, so it only suggests real ones.

Honest when nothing fits. When there’s no good match, it says so and shows the closest options side by side, instead of pretending one is right. It was the hardest call in the project.

“No exact match yet. Nothing in the library works directly on that. These two come closest. They gather the customer evidence most questions like this turn out to need.”

No fake “thinking”. Questions appear instantly. There’s a short pause only before the recommendation, where the work actually happens.

Tested before it shipped

Because I built it in code, people could use the real thing, not react to pictures of it.

From recommendation to work

A recommendation is only useful if people act on it. In the library, the results filter what’s shown. Inside a project, one click adds the playbook and starts it.

From stuck to started in about fifteen seconds, which is what the project set out to do.

Designing in code, with AI as a partner

I designed this in code, not Figma. I built the front end myself with Claude, and that code went straight into the product. There was no handover and no rebuild. Our engineer connected it to the data behind it, and it went live.

Who built what.

Claude helped with the rest of the work too, from summarising interview notes to brainstorming directions with me. Building in code changed how the whole project ran.

• Decisions were made on something real: a working product, not slides.
• Tricky cases showed up early, while they were cheap to fix, like changing an answer or finding no match.
• Testing was real: people used the actual product, so their feedback changed the design.
• Checked automatically: automated tests clicked through every step and caught things that looked right but didn’t work.

Results

The Recommender is live. When people got stuck at the first step, they didn’t see the value, didn’t come back, and some cancelled. Fixing that first step improved every one of those numbers.

The jump in people coming back says the most about the design. With the right playbook from the start, people had a reason to return, week after week.

Beyond the numbers

What this project shows about how I work

What’s next

Next: the full assistant. The Recommender fixes the first step. Next, I’ve recommended building Strattie AI, the assistant I prototyped at the start, to help at every step after that. It’s on the roadmap for the next year.

Why it’s now easier to build. The Recommender gives the assistant a head start: proof that guidance works (57% → 85%), a question map it can reuse, real examples of how customers describe their problems, and a working prototype.

What I’d watch until then: how quickly people start a playbook, how often they keep using the Recommender, and what people ask for that it can’t answer yet.

Shipping one focused thing first kept the bigger vision alive, and gave us the evidence for the next step.