How to ship a great product fast
TL;DR: My best advice for shipping fast is to hire a few of the best people you can afford, give them as much context as you possibly can, and let them crack on with stuff.
Storytime.
In 2016 I was working on a way for companies to give Deliveroo credit to employees. As Product Manager, I would find out from the commercial team what customers were asking for, and we’d build it.
The engineers would push back to my requests. They’d explain that certain things wouldn’t work as wanted, or that we could sequence the work differently to be faster in the long run.
I was playing middleman, and (like many PMs) I think I liked it that way. Commercial teams don’t typically work well with engineers, so I had a purpose. A reason to not get fired. We shipped some okay stuff, but weren’t having a big impact on Deliveroo.
One day I returned from honeymoon, and our team had a new objective. Deliveroo’s new CTO had looked around the company, and saw that our Live Operations (our ability to deliver food on time) was on fire. We’d grown too fast for our Live Ops teams to keep up with, and it was critical function for the company. No brainer - big problem to solve, and our team was given the job.
The trouble was: I didn’t have a clue how to fix it. It was super complex, and there was no single person to tell us what to build. There were many operations teams around the world, each with unique problems. There were no incumbent food delivery businesses to look to for inspiration. I wanted to impress the new CTO, but I had no idea what to build.
So I took our team of 6 engineers and a designer, and we downed tools. For one week, we did the Live Operations job ourselves. I needed to learn about how the ops teams worked, and I needed to buy myself time to make a plan. The team grumbled a bit about not writing code for a week, but I think secretly enjoyed it in the end.
At the end of the week, the tech lead (Greg) talked the team through his proposal for an issue monitoring system that we could build to completely change our Live Operations. I could never have suggested it - I didn’t understand the technology options well enough. Because how could I?
Several team members also somewhat sheepishly shared some tools they’d built in their evenings. They’d seen the pain their Live Ops colleagues went through, and had altruistically built ways to help.
The team had delivered more impact in that one week than any other time in my career, all without me doing anything. This forever changed how I approached product development.
I learned that there are only three things you need:
It’s quite simple: you need the best people, they need loads of context, and you need to let them do stuff. Without these, you (or some other context-keeper) become a bottleneck, and stuff slows down. Everything else is noise.
Firstly, you need the best people.
You need the best people because that’s how you win. If you’re building a venture-scale company, you’re shooting for $1bn+ valuations. You’re in the Premier League of startups.
And the best way to win the Premier League is to hire the best players. You maybe can’t afford the Haalands and Gary Nevilles of the world (is my lack of football knowledge showing?), but the better your players, the more likely you are to win. You simply will not build a great product unless you hire the best people.
There’s several other essays to be written about how to attract the best people, but here’s some things I’ve learned about them:
The best engineers are product thinkers. They don’t think in terms of code, they think in terms of what code can do. They want to solve problems. I think this should actually be a non-negotiable for any product builder, but it becomes extreme with the best.
They typically have experience at successful companies. Successful companies last longer, and go through more failures than failed companies. People that spend time at these companies will learn more from both success and failure. You can definitely get great people with different (or no) experience, but they’re diamonds in the rough. I’ve met a few of these people, but I have no pattern for how to spot them.
They look for the best other people to work with. The more great people you hire, the more you attract.
They look for interesting and challenging missions. They can choose what to work on, and you can’t compete with FAANG’s money. You can probably compete on mission though.
They typically aren’t the ones who spend time posting on social or writing blogs (I know, I know, shut up). They’re quietly building incredible stuff. People internally know them, people externally rarely do.
They don’t care about perks all that much. Having a great mission, and having a chunk of equity are far more important than a coffee machine.
Paying for the best is totally worth it. A fantastic engineer will create at least 2x the value of an okay engineer, so don’t lose them on a 20% pay difference.
Most importantly, they want to ship a great product, fast. They don’t like anything getting in their way. They don’t need pushing, they’ll push you. No amount of management will ever come close to replicating this innate drive.
For my part; I don’t think you can outsource great people. The best people typically look for a mission that they can go all in on (in my experience). One of the best ways to attract the people is to spend time crafting your mission, and putting that out into the world.
Then, you need to give them loads of context.
The equation for making product decisions is something like:
What Is Needed x What Is Possible
As a non-technical person, you’ll never learn what’s possible. Instead, give your technical people a way to understand what’s needed so that they can make their own decisions.
The best way for people to learn is to talk to customers. Have them do this until they’re sick of it. This lets them download the context directly into their brains, which is far more powerful than you telling it to them.
Just immerse them, let them swim in the context. Give them time to do this at the start, as well as a continuous habit.
This will serve several purposes:
It lets them properly understand customers. They can ask their own questions, and will get to deep, intuitive understanding much quicker than just being told things.
They’ll believe customers. Anything coming from a CEO or PM is filtered, and comes with bias. You might be massaging something to make a point. I think historians call it first degree sources vs second degree. First are always more reliable.
They can imagine the benefit to the person they’re helping, which makes them more productive. If the outcome of work is a 👍 from your boss, that’s not much incentive. If the outcome is to make real people genuinely happier, that is an incredibly powerful incentive.
Your objective should be that the people working on the problem have the most context on it. There is a beautiful inflection point when they’ll come to you with completely new insights, or challenge an assumption you’ve had. This is where they can ship fast(er) without you.
Finally, let them do stuff.
Once you’ve got the best people and they’ve got context, let them make decisions. Don’t tell them what to do unless it’s you have some critical information they don’t. Those bits of critical information are extremely rare.
It’s much better to have someone independently make the right call 75% of the time, than have you make it correctly 100% of the time on their behalf.
Every time you tell a smart person what to do, you train the wrong muscle. You strengthen their “shut up and do what the boss says” muscle, and weaken the “make my own decision” muscle. The latter is critical for moving fast for three reasons.
Firstly, when an engineer builds product they make hundreds of tiny decisions. The more of those decisions that you touch, the slower you move. And the worse the decisions made by the engineer because they’re not used to it, and ownership is diluted.
Secondly, the engineer will have access to ideas that you don’t have. They will know things that you don’t. Technical people make the best decisions around technology, period.
Finally, there are more of them than there are of you. If you distribute decision-making, the sheer bandwidth for decisions increases. Some of them might not be as good as if you’d made them yourself. But good people learn from bad decisions, and I’ll take a team making many decisions and learning fast over a single person slowly making the right call each time.
Someone I once worked with described the company like “walking with a stone in their shoe”. Every bit of friction at work gets in the way of people shipping stuff. There are many potential points of friction: decisions needing approval, allowing on certain softwares, every meeting they’re pulled into, every spending sign off. Every time they have to convince someone of something.
Friction also undermines your culture. I’m a big believer in Ben Horowitz’s view that what you do is who you are. If you have blockers, then you’re saying that impact isn’t the most important thing. You’re saying that the friction is more important than shipping.
The very best people want to win at a high level. You don’t win Premier League titles with stones in your shoes. The best people want to ship. It’s up to you to clear the path from anything that gets in the way, including yourself.