Product discovery for complex B2B software. The talk from ProductTank Helsinki, 2 September 2026.
Thanks to everyone who came out to F-Secure on Wednesday evening! I’m grateful for the opportunity to talk about my passion topic, product discovery for B2B software. I enjoyed the conversations, and a good number of you stayed outside afterwards to continue exchanging ideas.
If you registered for the event but something came up, this page is for you too. Everything from the talk is here.
What the talk argued
I opened by asking how many people had built something a customer had asked for and then didn’t use. Almost every hand went up, mine included. Everyone in that room talks to their customers regularly, which makes the question interesting.
Talking to customers gets you pain points and feature requests. A pain point tells you that an existing solution doesn’t fit the underlying problem. A feature request tells you what someone imagines a solution should be like. Neither of them describes the real underlying problem, so they can’t help you figure out the right solution to build. They are only a starting point for discovery rather than the answer.
I brought two shoes along to make the point. One of them gives me blisters. But a blister tells you the shoe doesn’t fit the foot, but not the shape of the foot. You cannot design a good shoe based on blisters. If you try, you end up just with softer linings. Worse yet, while I’m wearing the shoe you can’t see the foot at all, which is roughly the position that we are in when we study how customers use our software. The solution (shoe) is visible, the underlying problem (foot) isn’t.
A customer problem is a concrete situation: what someone is trying to achieve, why, in what circumstances beyond your control, and by what criteria they judge whether the result is good. That situation exists whether or not anybody has built a software for it. Once you can describe it exactly, most of the design follows by reasoning, and you can measure a proposed solution against the situation before anyone writes code.
Shoe shops have measured feet with the Brannock Device since 1925. In software, we still mostly ship a solution and ask customers if it causes blisters.
The case I walked through was RELEX Solutions entering assortment management, a market where competitors had tried and failed despite obvious demand. I conducted six months of systematic discovery before development. Then a team of 3-4 people built the product. In the first year, they got 5 enterprise customers, a pipeline on track to 20+ customers globally, and an IDC Leader rating for the first release.
Try the Backlog Test tomorrow morning
Take the top five items on your roadmap and spend a few minutes on each. Write down the customer’s situation in which the item is supposed to be useful: what they are trying to achieve, why, in what circumstances beyond your control, and what criteria they use to evaluate the result. Then cross out anything in your description that refers to today’s tools (including your own product and your competitors’), how they are used, and the processes, roles and hand-offs of a particular organisation. Keep only what reality imposes.
If you can’t write that description, you don’t yet know whether the item is the right thing to build.
If you missed it: Summary and slides
Summary of the talk on one A4 sheet (PDF) summarises the argument in the order I presented it.
Slides (PDF) if you want the diagrams and the full RELEX case.
If you were there, I need your help
There wasn’t much time for Q&A, and I want to develop this talk further and give it elsewhere. Feedback from the audience is priceless, as I don’t know how well my talk (the solution) fit your situation (the customer problem)!
I’d like to know what was the most useful thing in it, what remained unclear, what did you disagree with, what did you want more of, and what was slow or boring. Blunt is better than polite.
If you can give me 15-20 minutes of your time to give feedback, book a meeting here, or send a message and we’ll schedule a time. Or if you prefer giving your thoughts in writing rather than talking with me, that would still be genuinely useful.
My newsletter on B2B SaaS product discovery
I publish Deductive Discovery, a newsletter for B2B SaaS product leaders who want a more direct route to problem-solution fit. I write about why products fail at a fundamental level, how to discover customer problems instead of collecting pain points and feature requests, and what AI changes about product work, along with what it doesn’t.
New subscribers get my report How to Build a Lasting Competitive Advantage in B2B SaaS, based on interviews with 31 B2B SaaS executives and founders.
Work with me
I’m Antti Latva-Koivisto. I’ve spent over 25 years in B2B software development, at Nokia, at Comptel, and as a consultant to companies including RELEX. I help product leaders work out what customers actually need, rather than what they ask for.
If something in the talk was related to a problem you’re currently facing in your product work, I’m happy to talk about it, no strings attached.