Product discovery now that AI is useful

In a talk at the Bart.js meetup in Trondheim, product discovery expert emphasized that AI now enables rapid prototyping and enhances workshops, making it easier for small teams to validate product ideas. He advocated for continuous discovery and delivery, using opportunity solution trees and health metrics to avoid building the wrong product.

Product discovery now that AI is useful Last night I gave a talk at the Bart.js https://www.meetup.com/bartjs/ meetup in Trondheim about product discovery, and what AI is doing to it. I had one hour, so we sped through the theory, experiences from three of my customers, and some ranting at the end. These are the main points. First, a confession I have built things that crash. Worse, I have built features with so little use value that I could not find a screenshot of them for the slides. The real risk in product development is building the wrong product. No value for the users means no value for the business. Why is the right product so hard? Users have their own motivation for using what we build, and only production tells us if something works. The solution space is not infinite, just very, very large. Too often we build because we can. And software has no value of its own. Alone it is only risk and cost for the organization. The users create the value. We care about deadlines, delivery scope and happy stakeholders. We should care about the four risks instead. Value, usability, feasibility and viability for the business. Add a human quirk. We love adding things and hate removing them, so products accumulate. The answer is two modes running side by side. Continuous discovery answers what is worth building. Continuous delivery answers how to build it. Lean too far one way and you end up in the analysis trap, where nothing ships, or the build trap, where you ship things nobody needed. So split the work into small bets. We bet that something gives value, measure it, and steer by what we learn. Every change is a hypothesis to be tested against reality. Three things that worked Opportunity solution trees Set the outcome first, visualize what you already know, then map opportunities and solutions under the outcome. My first tree looked like real life: messy, too wide, nothing like the examples in the book. That is the point. The mess shows the team’s current mental model, so the team can improve it. Wording matters too. A branch called “build a dashboard” closes thinking. A branch called “planners cannot see early risk signals” keeps several solutions alive. Use the tree to set OKRs and you get a strategy layer for free. The objective names the direction, the key results measure progress, and the tree explains the bet behind them. Measurements Insight is like eating vegetables. You know you should, some think they taste funny, they have to be fresh, and it only works as a habit. Health metrics should tell you something broke before the users notice. Product metrics show what users do, and business metrics whether it mattered. Pair the numbers with talking to users, so “what” meets “why”. And even when a user asks for something and it is a good idea, do not jump straight to building. There may be an idea worth more. Prototyping turned up to 11 Write the hypothesis first: we believe X, for user group Y, will lead to Z, and we know we are wrong if we see A. Then discuss less and prototype more, together with the domain experts. Nobody can picture a requirements specification, but everyone can point at a screen and say what is wrong. What AI does to all this The prototype has risen from the dead. If you can talk, you can make a web app, my kids included. The paper prototype has gone digital, and with a design system on top it stops looking soulless. Your strengths are still yours, and AI covers the rest of your knowledge. Nobody works alone anymore, and a small team performs like a big one. Workshops are easier to run, with AI as the world’s best workshop friend before, during and after. Summarizing and reshaping knowledge for different audiences takes little effort. And measurements were always important, but they are now both more important and easier to set up. Build just enough to get an answer: - Do they understand it? A paper sketch. - Do they use it? A clickable prototype. - Is it possible? An ugly script against real data. The catch is that easy to build is not the same as easy to build right. The threshold is so low that some skip “start small” and go straight to overdesign, too many features and complexity from day one. AI is still bad at design and needs a person to guide it. Developers still own architecture, scale and security. Judgment is not automated. If you do not know what you want, you cannot get it either. Speed gives us room to learn, and the gain is more time for the craft. It is tempting to build too much and spread the focus, because building is so easy now. Don’t. Chase the value instead, or you end up with even more features nobody can find a screenshot of.