We’ve talked for years about being lean, agile, and iterative. Strangely, “Fail fast” has become a mantra. But the result often ended in fail, not in fast. The so called agile projects failed, and often did it after quarters or years.

Why? Because as soon as the specification or agile "epics" have been set, things get stale. Decisions and contracts are made, and performance evaluations get set.

Why? Because testing multiple ideas simply has been too expensive. Prototyping took time. Design work needed coordination. Engineering was a bottleneck. So once one approach was selected, the focus shifted to execution — and because goals were set, the concept was often built and launched, regardless of early customer signals.

Old agile thinking

The old agile thinking was programming-oriented. Build a skateboard to test the customer needs before building out a full car. Because building a car is too complex and takes too much time.

But is really a skateboard useful if the customer need is drive fast and to show off his wealth at the Grammy Awards. And what part of the business model do I test with a working skateboard?

Agile development talked about testing a skateboard before building a car...

While the analogy worked in 2001 to compare it to old waterfall processes, in reality it just led to phased programming of the product. We didn't test the real customer need for a car before the prototype car was developed a year later.

Now, that’s changing. The real value of AI in product development isn’t just faster programming. It’s the ability to test more ideas, with less effort, in a shorter timeframe. This unlocks a new kind of product cycle — one that’s truly iterative.

From roadmaps to parallel tracks

I view the product strategy less as any one specific thing, and more as how do we iterate and learn as quickly as possible…If we can learn faster than every other company, we're going to win. - Mark Zuckerberg

Traditional product cycles are built around quarterly planning. The popular agile framework SAFe calls them program increments. You define strategies, goals, lock the roadmap, assign teams, and execute. That model actually optimizes delivery — but often slows learning.

Because getting to a prototype that can be tested with customers was expensive, senior management approvals were needed. And approvals often require lots of documentation to be produced even before you know if it was a good idea. And once the decision is made, its set in stone.

To make things worse - in many companies, the senior management level product decisions were made year by year, slowing the process down even more.

It doesn't have to be this slow.

Classical product development

In the best of cases, the business development process at least had a free-thinking concept development phase, where different potential solutions were assessed iteratively, on paper. But after the evaluation of the different concepts, the business case was often set in stone, including a hypothesis about the user needs, that may or may not have been properly validated. And after leadership has approved and started a concept, it is difficult to go back and change it.

Why is this a problem? Because as long as things just are on paper or in wireframes, it is super difficult to evaluate if something is right.

The classical process - it ensures there is a viable business case built, but most things are already decided before we can evaluate it with customers.

Parallel business development

Things have happened.... With AI-powered prototyping and content generation, companies can now shift from building upon guesswork to easily testing assumptions.

Iterative development has been promoted for years, with mixed outcomes. The big change now is that we can build and test many business ideas in parallel. We can build three different concept prototypes in an afternoon. This leads to a super-interactive business development process, at a low cost.

Business development, product definition and development is now fully intertwined.

You can now ideate, prototype and test several ideas in a week.

Key aspects of this new way of working is that:

1. We get useful (customer) feedback in each iteration - which helps adjusting the concept and business case

2. It’s now a cycle measured in weeks, not quarters — and the output is confidence in success, not untested features.

3. Mentally it's easier to let go of a failed one week test, than something you have invested time, energy and money into for months.

4. We get user feedback before we create extensive product strategy documents, business cases and project plans.

How to enable week-based product cycles

The way you construct your process and organization is a bit different now. It is not necessary anymore to have huge teams. Its more useful to have a tight multi skilled team.

1. Compact, cross-functional teams

Small, senior, multi-skilled teams can often move faster than traditional teams of ten. You can start with just one or two people with the right tools and ways of working.

For most cloud or mobile oriented products, I would recommend that you start with people that have skills in Product Management, UX and AI-prototyping. For instance:

1. A tech-savvy Product Manager that can set the product strategy and goals, but also specify the needs in a way that enables an AI to build prototypes.

2. A customer oriented UX expert - being the customer advocate, focusing on researching customer needs, testing the hypothesis, and being tough on the product prototypes. Being strict on validating whether the current ideas and concepts really delight the customer.

Gradually build out your team, based on needs, for instance with

1. Full-stack Development - gradually add system integrations and move to secure, maintainable and build robust components. Ensuring proper datamodels and system design early.

2. Marketing - Someone who can work on all messaging, content marketing and different campains needed to get early customer signals and build awareness.

3. Design - ensuring that the graphical profile works with the corporate identity and strenghens the product vision.

4. Testing and Operations expertise - that can set up tests and operations flows like a robust CI/CD, secure and robust environments.

2. Validation Criteria

Rapid business development is about proving that you are on the right path. Showing that the idea is viable, for users, the business, and with working technology.

So, how do you choose? What makes one of your three concepts better than the other?

Set the goals the first one or few weeks, for instance:

• Validate if our assumption on customer need is correct.

• Which of our product ideas gets best customer feedback. Is it better than any replacement product?

• Is there a will to sign up, what is the willingness to pay?

3. Prompt-driven prototyping

Use tools like Lovable.dev or Cursor to spin up multiple working versions of critical app flows in a day. No need to wait on full specs or design sprints.

The value of this is that you can easily see if the product or feature idea works in reality with a clickable prototype. You can also do realistic tests with users. And you will get immediate feedback on everything in your prototype, from features, response times and graphical profile to the messaging and copy. 1000x better than an interview or tests with wireframes.

Read my article about AI-driven business development and prototyping to learn more about how to leverage AI in the best way.

4. Tight validation loops

Show rough versions early. Use landing pages, limited workflows, quick integration tests, user interviews — anything that gives you user signals fast.

Make sure that the first validations are about testing the key hypothesis and validation criteria of your app: E.g. will it solve a customer problem, is the user experience right, will we get the right click to actions.

5. Decide based on learning, not sunk cost

Once something is validated, go. If it’s weak, kill it. Just because it was the first idea doesn’t mean it’s the right one.

The good thing is that we now tested all good ideas at the same time. So the time and cost to failure was neglectable, and we can continue next week with the most promising ideas.

Summary

The tools are finally good enough to allow true agile business development. The cost of trying something is low. There’s no excuse to default to one big bet per quarter or year anymore.

The real competitive edge in the AI era isn’t programming efficiency — it’s speed of business development. - Johan Eliasson

Allow your teams operate in parallell. Get your feedback loops in weeks instead of quarters:

• Explore multiple directions, not just one

• Reduce waste from building unvalidated ideas

• Respond faster to shifting customer or market signals

Need help to speed up business development?

Please feel free to reach out to me on TeamPilot. I would be happy to eduate your leadership teams, or help implementing agile business development in your organization.

Johan Eliasson