What should you prioritise when building a new team?

Lessons from two decades of mistakes and growth in startup tech industry

Someone asked me a great question:

What would I do if I were building a new startup team from scratch?

It’s easy to get lost in the weeds trying to optimize everything while at the same getting advice on staying lean and not optimizing anything. Advice always depends on the giver’s assumption-stack.

The list below contains actionable areas for tech startup concerns that I have found addresses common assumptions in a growing, flexible business.

✄ Cut away requirements, then cut some more

Scope creep starts at the product input level. Don’t even talk about features that are not actionable this week or valuable.

Remove maybes.

Remove wish-lists.

Remove “after launch”

You want the launch to be lean and sooner rather than fat and later.

📉 Maximise features not built

Using event modelling you can chart out the entire flow of data and complexity on a timeline.

What is unique to your business is usually at the end. Start with that.

Avoid building common, commodity features that are not unique to your business.

You want bad news as soon as possible.

Before you invest time in building something. Once you’ve invested the time, the retrospective won’t get you the time back.

🎢 Build versions 1, 2, 3 rather than features 1, 2, 3

Your first version will suck.

The second one will be painful.

The third one is polished.

The fourth one you find something important.

The fifth time you find out what high-ticket clients really wanted in the first place and build that instead.

Manage your business and engineering focus:

• Strategy: Get to version 5. Avoid attachment to prior investments. Don’t get caught polishing version 1 as if it’s very valuable because it took a long time.

• Tactics: Get the current version into the customer’s hands as soon as possible to get green light on building the next one.

Remember: every new version increases revenue from the customer.

💰 Everyone need to understand what is valuable to the customer

The most important quality in an engineering team is having engineering understanding and business understanding within the same skull.

Not sign-offs.

Not hand-offs.

Not specs.

Not meetings.

Understanding.

When your team understands where the value is, they will stop second-guessing themselves. The stop-and-go from trying to understand mid-process is the biggest source of wasted rituals.

🍱 Actively experiment, rather than build

Build a pop-up feature like you would a temporary lemonade stand.

Make it modular. Lightweight. Moveable.

Easy to discard.

If the experiment shows value, you can build a shop there.

If it doesn’t, you avoid the mortgage.

🚚 Bring value to the customer

Value not delivered is revenue not captured.

If an important feature can marinade on a feature branch for 2 weeks, it’s not important. Don’t finish it. Cancel it.

Catch yourself communicating “Can you hurry with X, we need to start on Y?”

Starting deadlines are important. Cancel X immediately and start working on the priorities.

Integrate fast, deliver quickly.

The best features are those that a customer is already waiting for.

📏 Then I'd listen for signals and double down on what's working.

And stop doing what isn't.

Question everything.

The process.

Agile.

The competition.

The doubters and haters.