We recently released an advanced feature in our app that took us just 10 days to build. It was challenging, but we learned valuable lessons along the way. Building a product or feature is tough, primarily because you have to handle complexity and ensure reliability. We've observed many startups and founders falling into the same traps repeatedly. Our solution? Moving fast.

In this post, I'll share three key concepts we value to maintain speed in product development:

1. Starting without building

2. Moving fast while writing code

3. Leaving cushions for unexpected issues

But first, some context: We're creating an AI workforce, starting with sales and marketing agents. Our focus is on selling the work itself, not just a solution to manage work.

1. Starting without building

This is the most critical part of the process, and it's more than just "scoping." Knowing what to build is 90% of the job. It's also when you can decide to scrap the whole project if necessary.

a) Let go of hope and vision

It's easy to believe in your idea, but worry that no one will care once it's built. Here's a common scenario:

You create mockups in a few days or hours and show them to prospects. They respond with enthusiasm:

• "This looks awesome!"

• "I'm so excited for you guys!"

• "Let me know when I can test it!"

• "I'd love to play around with it!"

You spend months building it, send out invites, but no one signs up. Those who do sign up don't use it and quickly churn out. Sound familiar?

Let go of hope and vision. This is a game of desperation, and the winner is the one who can hold out longer. When you hear positive feedback, dig deeper.

b) Digging deeper

If you're hearing positive feedback, ask them to pay. For example: "We can deliver this to you next week. It would cost $100. Can you pay now?"

If you're hearing negative feedback, still ask them to pay: "Got it. We'll add this feature. It should take only 30 minutes. Can you pay $100 for it now?"

The answer is rarely a straightforward "no." Instead, you might hear:

• "Yeah, but I need to see it and test it first."

• "Let me know when you have a version ready."

• "I need to talk to my manager."

• "I wouldn't pay that much."

These responses are the worst because they tempt you to hold onto hope. You're lucky if the prospect says:

• "You know, it's not worth that much to us."

• "It's not critical for our needs."

These responses tell you that you shouldn't build this feature or product.

2. Moving fast and writing code

Once you've nailed down the need, gotten paid, and started coding, the only thing that matters is simplicity. Being simple doesn't mean dysfunctional – it's quite the opposite. Being complex doesn't guarantee flexibility or functionality.

Simple is much harder than complex. You need to find a way to build:

• A simple product

• A simple way to build it

I find it useful to look at two products as inspiration:

1. Shazam

2. Excel

Start by building a "Shazam-like" experience: Click, and boom – the user gets the result. However, build it in a way that allows users to customize and expand functionality if needed, like coloring cells in Excel.

Don't be tied to what you've built. Be prepared to scrap everything and start over if necessary. Avoid the sunk cost fallacy.

3. Leaving cushions

No matter what you build, there will be bugs – probably more than you expect. Embrace this reality. Nobody cares about the bugs as much as you do. What matters is how quickly you fix them.

Leave cushions in your planning. If you think there will be 3 bugs, prepare for 30. When you discover them, fix them immediately. Stop reading and start fixing.

Conclusion

This post offers a general overview of our approach to building products quickly. In the future, we'll dive deeper into specific aspects of this process. If you'd like to hear more from us, follow us on our social media channels:

→ Twitter

→ Linkedin