Kieran Erasmuson is sitting in a pharmacy, taking notes.
He’s not a pharmacist and doesn’t understand everything he’s observing. Week after week, he watches quietly and patiently.
Then Puneet Saini begins processing a prescription. A complex one. Escalating doses, specific quantities, and legal validations. In seconds, without reaching for a calculator, without pausing, Puneet works it out in his head and moves on.
Kieran stops him. “Hang on. What did you just do there?”
Puneet looks blank. “What do you mean? I just… worked it out.”
He hadn’t noticed. He’d been doing it for years.
That seamless calculation – validation, escalation, confirmation – became a core problem they aimed to solve. Kieran, not knowing what he was seeing, kept looking until it became clear.
Does this sound familiar? You’re close to a problem. You know the industry. You’ve lived the pain. And somehow the solution still doesn’t land the way it should.
About this week’s contributors
Kieran and Puneet are co-founders of Script Sense, a New Zealand health-tech startup rebuilding pharmacy management software. Kieran has a background in hospitality operations and tech. Puneet is a qualified pharmacist and self-described unlikely entrepreneur. They teamed up with technical co-founder Rijul Gupta. Together, they are changing how pharmacists work and, in turn, how patients are cared for. They are a contributor to our new book Innovation in Action.
The startup world has a default setting. Move fast. Ship early. Fail cheap. Get to market before you’ve over-engineered the problem.
It’s not bad advice, but it’s incomplete. This is most evident in high-stakes sectors where misunderstanding the problem leads to lost years and mistrusted products, not just pivots.
They challenged this norm. They treated design thinking not as a workshop but as their operational core, from understanding the problem to building the team to defining their testing approach. Starting slow made the rest faster and more certain.
Here are the most important lessons they learned:
Articulate the problem behind the problem.
The pharmacy management software market had existing competitors. They had been there for decades. One had charged customers for a spell-check feature – in an era when spell-check was standard in every consumer application on the planet. The market hadn’t changed because the incumbents had no incentive to change it. They owned it.
That context matters. When Kieran and Puneet began their discovery work, they didn’t just look for product features. They searched for what two decades of stagnation had made invisible.
Kieran deliberately chose to enter the problem as an outsider. He is not a pharmacist. He came from hospitality and tech. And rather than treat that as a disadvantage, he weaponised it.
“I didn’t understand the use cases at all. It was a very deliberate choice to stop ourselves from jumping to solutions and say, I need to go into a discovery phase and just observe.”
So he did. For months, Kieran sat in pharmacies around the country – watching pharmacists, not just talking to them. This, called field observation in the DUCTRI framework, means watching the work itself, not just interviewing experts. It’s slower. It’s less efficient. But it surfaces things no interview ever could.
The invisible calculation was the proof of that. Puneet, with seventeen years of pharmacy experience, had internalised an entire validation process to the point where he could no longer see it. It had become instinct. Expertise had made it disappear.
This is one of the most underappreciated dynamics in innovation. Those closest to a problem are often least able to articulate it, because deep familiarity turns complexity into habit. A pharmacist dispensing ten thousand prescriptions doesn’t think about how they do it, any more than an experienced driver thinks about shifting gears.
The outsider’s naivety wasn’t a liability. It was the instrument of discovery.
If your discovery process relies entirely on people who already know the industry, you will find the problems they can still see.
Design your team.
Most teams are assembled based on shared goals. Script Sense’s founding team was built around what makes a great team. That distinction shaped every discovery and testing conversation that followed.
Puneet is the pharmacist. He understands the workflows, the regulatory environment, and the human cost of getting it wrong. He feels the problem because he has lived it. But as the invisible calculation showed, that same proximity had compressed his view. He needed someone who didn’t know what normal looked like.
Kieran brought the commercial and operational perspective, and, crucially, the fresh eyes that sustain the curious observation required. His background in running multiple kinds of businesses within a single organisation gave him a trained instinct for where efficiency breaks down at scale. He could see what Puneet had stopped seeing precisely because he had never seen it before.
Rijul, their technical co-founder, is an engineer and PhD candidate in machine learning. But what made him indispensable wasn’t just his technical capability – it was his ability to translate between technical reality and commercial stakeholders in the same conversation.
In design thinking terms, he held the feasibility lens: not just ‘can we build this?’ but ‘what does building it actually require?’
The practical value of this composition became evident repeatedly. “A lot of times when I was not able to put a point across to a stakeholder, Kieran was able to pitch in and put the same view from a different perspective,” Puneet explains. When a technically-minded investor entered the room, Rijul took the lead. When a pharmacy owner needed to understand the clinical implications, Puneet stepped forward.
This is intentional team design. The three lenses of user, commercial, technical – map to the desirability, viability, and feasibility questions at the core of innovation. No single founder had all three. The team held them together. That made every stakeholder conversation, discovery session, and test iteration richer.
Before considering your team’s skills for building, first ask what unique perspectives your team can collectively bring to problem discovery. The team’s vision shapes everything that follows.
If these insights resonate, there’s more available.
Innovation in Action launches on 1st July (Australia) and 1st August (New Zealand). Christian and I wrote it for exactly this kind of challenge – the gap between having a good idea and actually getting it to stick.
The DUCTRI framework’s Discovering and Testing phases follow the same principles as those used by Kieran and Puneet. It comes with step-by-step tools you can use right away.
Everyone who pre-orders before launch gets access to the Activation Q&A — a live session with Christian and me where we work through your specific challenges directly. Seats are limited and won’t roll over after launch.
Pre-order here.
Design your MVP for learning and trust.
Before Script Sense had a single investor, a product, or a team beyond the three founders, Kieran and Puneet built a demonstration prototype. They took it to a pharmacy trade show.
It didn’t connect to anything. It couldn’t process a real prescription. It was, as Kieran describes it, “a demonstration of what this product would do if it were built.” Built on their own money, for one purpose: to test whether the market wanted what they thought it wanted – and whether their problem framing, built on months of field observation, was actually correct.
This is the testing phase of design thinking at its purest. Not testing a finished product. Testing an assumption. The assumption being: we have understood the problem correctly, and people will pay to have it solved.
The response confirmed it. Pharmacists who had been using the same software for decades told them, “We’ve been waiting twenty-five years for something like this.” One consistent theme emerged from the hundreds of opinions gathered: remove the pharmacist from the keyboard so they can spend more time with the patient. That single insight, surfaced through a non-functional prototype at a trade show, became the north star for everything Script Sense built afterwards.
But the prototype was only one kind of test. And this is where design thinking in complex sectors demands a more sophisticated understanding of what testing actually means.
In healthcare, a minimum viable product means something entirely different to what it means in consumer tech. You cannot ship a pharmacy management platform the way you ship a note-taking app. There are third-party integrations, government data standards, regulatory requirements, and patient safety implications that define a floor well above what most startup frameworks would consider viable.
“An MVP in the health tech space is not really an MVP, it’s either viable or it’s not viable.”
From trade show to first installation: twelve months.
The lesson isn’t that healthcare is slow. It is that every sector has its own definition of the minimum standard of trust required before a customer will commit. The trade show prototype was the right instrument for testing market appetite. It was never the right instrument for testing clinical readiness. Knowing which kind of test you need, and when, is the difference between useful validation and expensive misdirection.
Design thinking doesn’t prescribe a single definition of MVP. It asks you to be honest about what you are actually testing and whether your testing instrument is appropriate for the question you’re asking.
Practitioner Insights
Three things worth taking into your next piece of work.
Slow down at the front end – deliberately. The pressure to move fast is real, and it is not entirely wrong. But speed applied before you understand the problem doesn’t accelerate innovation – it accelerates the wrong solution. The DUCTRI Discovering and Understanding phases are built on the principle that the quality of what you find is directly proportional to how long and how curiously you look. If your discovery process is measured in days, you are finding the problems people can already articulate. The ones that matter take longer to surface. Build that time in at the start, not as a luxury, but as the highest-leverage investment you can make.
Compose your team around lenses, not just skills. When assembling a team for innovation work, the instinct is to map skills to tasks. The Script Sense approach suggests a different question: what perspectives do we need in the room to see this problem fully? User, technical, and commercial lenses. They make discovery richer, testing more honest, and stakeholder conversations more effective. A team that can see the problem only from one angle will find solutions visible only from that angle.
Define what a minimum viable product means in your context before you build anything. The MVP concept is one of the most widely applied and most poorly contextualised tools in the innovation playbook. Before you design your testing strategy, ask two questions: what assumption am I actually testing, and what does my sector require before it will trust what I’m showing it? A prototype that validates market appetite and a prototype that validates operational readiness are two entirely different instruments.
Want to go deeper?
Watch the full conversation with Kieran and Puneet on YouTube where they walk through the Script Sense journey in full – from pharmacy observations to second seed funding and the road to scaling.
Connect with Puneet and Kieran on LinkedIn, where they share the ongoing Script Sense story.
Immense thanks to Kieran and Puneet for their generosity in this conversation. There is something refreshing about founders who are still close enough to the origin story to remember exactly what they were thinking, and honest enough to say when the playbook told them one thing, and the problem demanded another.
A question to sit with this week: In your last innovation project, did you slow down long enough at the front end to find the problem behind the problem — or did you move to a solution before the real insight had a chance to surface?