- Fri, 21 August 2026
In some of my product training courses, I have people break into small teams of three or four and set them the task of drawing a beautiful summer meadow. (Exercise created by David Barnholdt, originally published on Crisp’s blog in 2009.) However, I set the teams up differently; some teams have the instruction:
“Draw a beautiful summer meadow with blue and red flowers in green grass, some cows and birds under a shining sun.”
Other teams receive a much more detailed specification:
“Draw a beautiful summer meadow with:
After ninety seconds of frantic drawing, we pin the newly created works of art to the wall, and the whole class flips into art-critic mode. The teams with the single-line brief have generally created some beautiful summer meadows. The second teams usually produce pages full of flowers, cows and birds. Technically, they have implemented some of the requested features. Yet very few have created something anyone would describe as a beautiful summer meadow. They become so focused on implementing the specification that they stop thinking about the purpose: creating a beautiful summer meadow. Somewhere between the customer problem and the product team, purpose has been replaced by specification.
The first teams have fun being innovative and creating a piece of art, while the second teams are stressed, implementing all the required features. Those of you involved in delivering products to customers may recognise this: you have a roadmap crammed with features; you have shipped 42 new features this month; you have reached 96% completion; and everyone is busy. Success. And yet you are not attracting new customers, you begin to lose market share, it’s inexplicable. Once the purpose disappears, the team is no longer being asked to solve a problem. It is being used as a production line to implement somebody else’s answer.
The organisation isn’t building products; it’s shipping features.
In the post-mortem, we ask: which features actually mattered? Silence, nobody knows. There has been a lot of effort from across the organisation, but there is little evidence about what is actually useful to customers.
Feature factories rest on a dangerous assumption: if we produce more output, we must be creating more value. But customers do not buy features simply because they exist. They value products that help them make meaningful progress or solve real problems.
And yet the conclusion is often that we need to go faster to keep up, more developers, better AI tools, and improve automation. Someone suggests we simply need better estimation, as though predicting the wrong work more accurately somehow makes it more valuable. Investments are being made to improve the tools and hire people; the engine is purring faster than ever, but the outcome is the same: no shift in impact for our customers.
Yet leaders now have another lever to pull: AI. It will dramatically reduce the cost of building products and create unprecedented speed to market. Unfortunately, many will discover that building features isn’t the bottleneck; the problem is understanding customers. So the risk is we just build the wrong thing faster. Our products are packed with features that nobody uses, which actually make them harder to use and ultimately less valuable to our customers.
Building faster does not solve the problem. The problem here is not execution; it’s discovery.
Purpose returns. Teams begin thinking again; they are not implementers of specifications, they are creators focused on solving customer needs.
Some people get nervous when the conversation turns to the idea of failing fast, but really, what we are talking about is learning fast. Spending six months building the wrong thing is not a roadmap you want to go down. We need teams set up for experimentation; some hypotheses will be disproved. That is useful learning. Others will gain support from the evidence. That is useful learning, too. The enemy isn’t failed features; it’s never discovering they weren’t needed.
With a small enough hypothesis and increasingly with AI, a learning cycle might look like this:
Getting here is hard; there is safety in the roadmap, as it feels safe in the belief that you know what you are doing. But when you think you know the answer, you stop asking the questions.
The real test comes when customer evidence contradicts the roadmap. A feature has been promised, budgeted and partly built. People have invested time, reputation and emotion in it. Do we follow the evidence, or finish it because stopping would feel like failure? Continuing to build something customers do not need is not perseverance. It is refusing to learn. Stopping in response to evidence may feel like failure, but it is progress.
In a production line, thinking is separated from doing. Somebody defines the solution, breaks it into requirements and hands it to specialists to implement. The people closest to the technology are not asked whether the solution makes sense, and the people closest to delivery are often kept far from the customer.
A genuine product team owns the problem, not merely the implementation. Engineers, designers and product people work together to understand customers, explore possibilities and remain accountable for outcomes. They talk to customers, investigate how people operate in the real world, discover pain points and create possible solutions. Nobody is simply implementing tickets.
Yes, AI can help with implementation, but that frees humans up to think, discover, create, and experiment. Human creativity needs to come first; AI amplifies it rather than replaces it.
These patterns reconnect purpose, customer understanding and implementation.
Rather than beginning with requirements or solutions for the team to implement, enable the team to understand customer needs directly. The team conducts direct research and engagement to ensure that genuine user demands guide product development.
Give people the purpose and customer need, not just a list of requirements. Start with the problem customers need solved, not the features someone has decided to build.
Team Ownership means the team owns the work from the initial idea through delivery, customer use, support, product evolution, and benefits realisation. Teams are not merely handed specifications to implement; they remain connected to the purpose and outcomes of their work.
When teams own only implementation, they optimise the specification. When they own the outcome, they can innovate.
Lean UX brings customer feedback and iterative design into product development. Teams test prototypes and assumptions with real users before committing heavily to a solution. Lean UX is particularly relevant in the AI era because teams can quickly create and test prototypes. Use AI to shorten the distance between an idea and customer evidence, not simply to manufacture more features.
An MVP is not the smallest set of features a team can ship. It is an experiment designed to validate a product idea, learn from users and test the core value proposition before committing extensive resources.
This pattern challenges roadmaps organised around stakeholder demand, effort estimates, or feature volume. Potential work is ordered according to its likely contribution to customer and business value. The question is not, “How many features can we deliver?” It is, “Which opportunity is most likely to create meaningful value?”
When the shift starts to happen, you will see teams move from implementing solutions fed to them by other departments to truly self-managing teams that solve customer problems. You will stop rewarding teams for how many features they can ship (output) and focus them on maximising learning and customer value (outcomes). AI becomes a discovery partner, rather than just an execution accelerator.
When organisations replace customer purpose with detailed specifications, product teams stop thinking, innovation disappears, and people become parts of a production line. AI can deepen that problem or free teams to discover, experiment and create.
As AI lowers the cost of producing software, the ability to build software alone becomes less distinctive. Understanding customers becomes more valuable than ever. In the age of AI, the organisations that win won’t be the ones that build the most features. They’ll be the ones who understand which features never needed to be built in the first place.
Sign up our newsletter to get update information, news and free insight.
