Building the wrong thing is costly, yet many teams do it because they misinterpret what customers really value.
In this live episode of the Scaling Tech Podcast, David Bland joins us to explore evidence-driven engineering, how teams can use experiments, metrics, and customer conversations to make smarter product decisions.
David is the co-author of the widely acclaimed “Testing Business Ideas” (with Alexander Osterwalder), which has sold over 100,000 copies in 20+ languages and is trusted by executives, entrepreneurs, and innovation leaders worldwide. He is also a sought-after keynote speaker and educator, having lectured at Stanford, Harvard, Yale, and other leading institutions, while advising Fortune 500 companies on embedding disciplined, scalable decision-making into their growth practices.
With his deep experience at the intersection of product, design, and engineering, David is the perfect guest to unpack how modern teams can de-risk their bets and build products customers actually want.
Listen to the full episode on Spotify
Listen to the full episode on Apple Podcasts
Watch it on YouTube:
About Our Guest:
Name: David Bland
What he does: He is the co-author of Testing Business Ideas and the founder of Precoil. He helps executives make assured decisions before investing millions.
Company: Precoil
Where to find David: LinkedIn
Key Insights
⚡ Evidence-driven engineering is about building what matters, not just what’s possible. David Bland frames decisions around three overlapping risks: desirability (do customers need or want it?), viability (does it make sense for the business?), and feasibility (can we build it?).
As he explains: “What I’m noticing in companies is that engineering isn’t the biggest risk anymore. You all can build almost anything. A lot of the things failing that I see inside companies are failing because the customer didn’t want it. Or if they wanted it, they wouldn’t pay enough for it. And I do think engineering needs to be part of this conversation soon versus later, versus treating it as those three circles should be overlapping, not silos inside your work.”
⚡Define clear success criteria. Setting clear success criteria is essential to know whether your idea is actually working. Without it, teams risk moving forward based on assumptions or gut feelings instead of real evidence. David explains, “That acceptance criteria needs to be defined. Otherwise, you run the test, and you kind of shrug your shoulders and say, well, I think that worked and then you move forward. And you really need to come back and say, okay, did that actually support or refute the hypothesis or the evidence? […] So you do have to write it down or your brain will just [play tricks on you]. It’s a bias there. You’ll just basically buy into it no matter what happens.”
⚡ Understand customer motivations to build products they truly value. Data alone can’t reveal whether your product is delivering real customer value. You need to dig deeper than that and uncover the motivations and needs that drive behavior. David says, “My advice to engineering teams would be don’t over-optimize on the what? Because I see his companies just go way too advanced on all the A, B testing and everything. And then completely neglect talking to customers on why they did the thing. So we’re making these big bets off of what they did, but we don’t know the why.”
Episode Highlights
Use the “Desirability, Viability, Feasibility” framework to evaluate ideas before building
Before investing resources into building a product, it’s crucial to evaluate whether it’s worth pursuing. David suggests using the “Desirability, Viability, Feasibility” framework to guide these decisions, ensuring teams assess customer need, business sense, and technical risk upfront.
As he explains: “I’d like to see more participation from engineering leadership early on. And the way I view that is almost through three circles. So I call it Desirability, Viability, Feasibility. And so feasibility is a lot of the, can we build this? What are the risks about delivering this? And that’s usually where engineering shines. It’s not exclusively where they shine, but it’s usually where you can provide all your expertise about the risk. And I honestly believe that people need to know about that risk sooner, versus later, instead of trying to figure out, oh, wait, we actually can’t build this the way we thought we could, and it’s almost too late because we’ve made promises.”
Engineering is not just about code; understand the WHY
Great engineering goes beyond writing code. David emphasizes the value of being part of conversations about product decisions, even if you’re not leading them: “I would say from an engineering point of view, don’t neglect the why. And also don’t be afraid to be on these conversations, even if you’re not leading them. Take notes, just listen, you’re going to understand so much more context of what you’re building and why you’re building it by just participating in that. I honestly believe your most valuable time isn’t always writing code. There’s so much else that goes on there. And listening on these calls, just lock out some time every week and listen, there’s a lot you can learn about the why, and it’s going to end up impacting and shaping what you’re building.”
Be willing to be wrong and adopt a learning mindset.
Perhaps the hardest but most critical shift in evidence-driven work is to see experiments as opportunities to learn, not as validation of your own brilliance. This means being ready to abandon even your most beloved ideas if the evidence doesn’t support them.
David shares, “There’s a lot of mindset stuff here as well, like open to being wrong. And I fall in love with stuff too. I did this whole thing about the book, about how I tested the book, and the cover I thought was the best cover did not end up being the best cover for the book, in my opinion, and yet the book sold six figures. So I think it’s hard. It’s really hard. And we need to be able to work through this mindset shift together of it’s okay to be wrong. It’s okay to learn and iterate and move forward. And I think it’s still the one thing that’s holding us back right now. It’s not the tooling. It’s not all the solutions to do this work. It’s the ‘I don’t really want to be wrong, so I’m going to run this test for a very long time, or I’m going to put the success criteria so low that I can just hop over that bar and move on.’”