.png)
Hi, I’m Berni Fisher, VP of Product & Engineering at Appcues. This is my bi-weekly column for product leaders who don’t have the time to read columns. We are moving pretty fast, and every other week I’ll share one thing I’ve learned about building products right now.
I almost didn’t write this. Sara, who runs our content strategy here, asked that for my first blog column, I share what I’ve learned lately. But my first thought was I don’t know, I’m just doing my job.
We’re so deep in the weeds that I rarely come up and ask what would help other people. So here’s one thing:
Keep in mind, we’re a small team over here. Three PMs, and that includes yours truly. Between well-deserved extended leaves and vacations, I honestly can’t remember the last time we had a full team (until just this week - yeah!). That doesn’t bother me. I’ve always been the kind of product leader who is happy to pick up a shovel. This year, it’s been mostly shovel.
So the PRDs, we used to write them. Now our engineers get a verbal summary, or a quick prototype we put together in Claude. Enough for them to understand the core problem to solve. Then they run. There’s no more checklist for “is this feature in? Is this functionality in?”
Most of my day isn’t writing specs. Now, I spend my time reacting. Validating, invalidating, testing, reviewing what my team built, as fast as I can, because they’re already onto coding the next thing. They’re not waiting on me, they can’t. We don’t have the time to slow down.
Often, we’re both seeing the solution for the first time. I look at it and go oh cool, that’s how they pictured it, Or oh my god, what were they thinking? Sometimes in a good way! Sometimes in a “where could I have explained it better” kind of way.
This is a different kind of mental load on both sides. Engineers have to be more product minded and I have to drop the ego, respond faster, with less context than I used to have.
Here’s an example that happened last month. James posted a working prototype of a new feature in Slack with a note that basically asked everyone to roast him. It was pretty great. But larger than the fun roast, what he made was built for a product and engineering person, and the people we’re betting on to use Appcues day-to-day are marketers. So Elana and I did a quick riff on Claude and sent it his way. About an hour and a half later he had a new version and we got a big “Yes!!” from Ryan. All of it happened without a spec, it was literally ‘here’s who this is for. Go.”
This works because Ryan and I moved really slow to start. It feels weird to say now because at the time it didn’t feel slow. We spent around three months on the road with customers building out our product strategy. Fastest three months of my life.
We listened to hours and hours of calls, spent countless hours on zoom with customers and conducted blind interviews for another few months.
Then we documented it, presented it, and iterated until we got a clear vision. Here’s what we’re building. Here are our four value propositions. Cool. Everyone gets it, and leadership is aligned. It’s how we can get away with losing the spec. An engineer’s empowered to make a good call with that kind of context.
Product should always come from a place of the why and the what, not the how. I am not an engineer, I am not the solution person. Engineers thrive when you don’t tell them HOW to solve the problem, but when you tell them what the problems are, why they are important, and then you let them cook. So technically the spec is still there, but different.
PRDs are technically still there, but they look very different. Ryan and I sat down and wrote everything once at the strategy level, and then we did a lot of work making sure everyone could repeat it back to us.
So I guess in my first blog entry, if I had to find something to say to you, whoever you might be, it’s that if your strategy isn’t clear enough for an engineer to build without a spec, AI will only help you build the wrong thing faster. You have to go slow at first to go fast.
Product Development
TL;DR
Hi, I’m Berni Fisher, VP of Product & Engineering at Appcues. This is my bi-weekly column for product leaders who don’t have the time to read columns. We are moving pretty fast, and every other week I’ll share one thing I’ve learned about building products right now.
I almost didn’t write this. Sara, who runs our content strategy here, asked that for my first blog column, I share what I’ve learned lately. But my first thought was I don’t know, I’m just doing my job.
We’re so deep in the weeds that I rarely come up and ask what would help other people. So here’s one thing:
Keep in mind, we’re a small team over here. Three PMs, and that includes yours truly. Between well-deserved extended leaves and vacations, I honestly can’t remember the last time we had a full team (until just this week - yeah!). That doesn’t bother me. I’ve always been the kind of product leader who is happy to pick up a shovel. This year, it’s been mostly shovel.
So the PRDs, we used to write them. Now our engineers get a verbal summary, or a quick prototype we put together in Claude. Enough for them to understand the core problem to solve. Then they run. There’s no more checklist for “is this feature in? Is this functionality in?”
Most of my day isn’t writing specs. Now, I spend my time reacting. Validating, invalidating, testing, reviewing what my team built, as fast as I can, because they’re already onto coding the next thing. They’re not waiting on me, they can’t. We don’t have the time to slow down.
Often, we’re both seeing the solution for the first time. I look at it and go oh cool, that’s how they pictured it, Or oh my god, what were they thinking? Sometimes in a good way! Sometimes in a “where could I have explained it better” kind of way.
This is a different kind of mental load on both sides. Engineers have to be more product minded and I have to drop the ego, respond faster, with less context than I used to have.
Here’s an example that happened last month. James posted a working prototype of a new feature in Slack with a note that basically asked everyone to roast him. It was pretty great. But larger than the fun roast, what he made was built for a product and engineering person, and the people we’re betting on to use Appcues day-to-day are marketers. So Elana and I did a quick riff on Claude and sent it his way. About an hour and a half later he had a new version and we got a big “Yes!!” from Ryan. All of it happened without a spec, it was literally ‘here’s who this is for. Go.”
This works because Ryan and I moved really slow to start. It feels weird to say now because at the time it didn’t feel slow. We spent around three months on the road with customers building out our product strategy. Fastest three months of my life.
We listened to hours and hours of calls, spent countless hours on zoom with customers and conducted blind interviews for another few months.
Then we documented it, presented it, and iterated until we got a clear vision. Here’s what we’re building. Here are our four value propositions. Cool. Everyone gets it, and leadership is aligned. It’s how we can get away with losing the spec. An engineer’s empowered to make a good call with that kind of context.
Product should always come from a place of the why and the what, not the how. I am not an engineer, I am not the solution person. Engineers thrive when you don’t tell them HOW to solve the problem, but when you tell them what the problems are, why they are important, and then you let them cook. So technically the spec is still there, but different.
PRDs are technically still there, but they look very different. Ryan and I sat down and wrote everything once at the strategy level, and then we did a lot of work making sure everyone could repeat it back to us.
So I guess in my first blog entry, if I had to find something to say to you, whoever you might be, it’s that if your strategy isn’t clear enough for an engineer to build without a spec, AI will only help you build the wrong thing faster. You have to go slow at first to go fast.
Sign up for Quickcues and get our monthly updates!
.svg)
