We’ve begun preparations for a major product launch. For us, it’s a big deal; it’s exciting. It’s a really big commitment. It’s also the kind of thing that threatens to become a quagmire, a set of features perpetually in-development.

We’ve found that making the right thing – something people want – is intrinsically quite fast. By contrast, it’s all the other stuff that slows down product teams. It’s process, it’s distance between deciders and doers, it’s bloated specifications.

With this in mind, I’ve realized that our company has developed – largely by accident – some general principles for achieving product velocity. Some of these may be wrong, and we’ll likely change our perspectives over time, but I thought I’d share them here nonetheless.

Principles for product velocity

We should probably do less

All else being equal, there’s usually a trade-off between speed and quality. For the most part, doing something faster usually requires a bit of compromise. There’s a corner getting cut somewhere.

But all else need not be equal. We can often eliminate requirements … and just do less stuff. With sufficiently limited scope, it’s usually feasible to build something quickly and to a high standard of quality.

Most companies assign requirements, assert a deadline, and treat quality as an output. We tend to do the opposite. Given a standard of quality, what can we ship in 60 days?

Recent escapades notwithstanding, Elon Musk has a similar thought process here. Before anything else, an engineer should make the requirements less dumb.

Idiot mode usually works

We’re big fans of the midwit meme. Put simply, the midwit meme usually shows an idiot and a genius agreeing on a simple solution, while a person of average intelligence flails around complaining about complicated stuff.

Early in our company’s history, we challenged ourselves to operate in idiot mode as often as possible. When we’ve made mistakes, we’ve usually been overthinking things. We often arrive at a workable solution by asking ourselves, how would I do this if I were an idiot.

Some problems aren’t important

A small number of problems matter a lot. For example, we have to take security extremely seriously. It’s really not okay for us to cut corners there.

But we can choose to ignore certain other things. For example, we know that our front-end doesn’t look very good on mobile devices. For the foreseeable future, we’ll just need our customers not to use mobile devices. We’d obviously like for our software to look great everywhere, but we’re choosing not to spend time on our mobile layout. No one really seems to mind.

I’ll be damned if we ship dark mode any time soon.

Just make the thing

We don’t have a process for product development. We don’t do Figma mocks. We don’t write PRDs. We don’t really have a design system. We don’t do agile. We don’t have OKRs. We don’t even have a firm product roadmap. We don’t have any A/B testing or growth hacks.

Our customers are engineers, so we generally expect that our engineers can handle product, design, and all the rest. We don’t need to have a whole committee weighing in.

We just make things and see whether people like them.

Rewrites need to happen sometimes

Companies often think they’ll move faster if they defer technical debt as long as possible. That’s sometimes fine, but we’re comfortable doing major rewrites when appropriate.

Sometimes the fastest path to building the right thing looks like this:

1. Build the wrong thing
2. Realize it’s the wrong thing
3. Replace the wrong thing with the right thing

If it seems reasonably useful to eliminate technical debt, we’ll do it.

Pay vendors to do it

When possible, we buy solutions from vendors instead of building things in-house. For example, we use a vendor called Fern to generate our SDKs. They do a pretty good job.

Of course, using a vendor has significant upfront costs – these things are usually pretty expensive. It also restricts our freedom a bit.

But using a vendor is typically the right move. We have very limited engineering resources, and our engineering resources are really expensive. A week of a single engineer’s time costs about $5,000 in cash. It’s worth vastly more than that when we factor in opportunity costs (i.e. how much better off we’d be if we spent that engineer’s time on something else).

Relatively few things are actually worth building.

Don’t hire people

We don’t expect that adding headcount would increase our team’s output. Hiring is slow and hard. Onboarding and people management consume time. Even for a ramped hire, collaboration’s expensive.

It’s especially hard to bring on strong people, the kind of people that can contribute without a lot of support.

So although we have the resources to build a large engineering team, we do everything possible to stay small. It just makes life a lot easier.

Closing thoughts

To an extent that wasn’t obvious to us before, we’ve realized that product development shouldn’t take very long. If you know what your customers need, have a strong team, and avoid distracting nonsense, velocity is pretty close to inevitable.