Don’t ask the Horse. Focus on Alpha.
I read an old Zen story about a man riding a horse once. The horse was galloping fast, and it appeared this man is going someplace important. Another person standing along the road asked, “where are you going?” The rider yelled back, “I don’t know. Ask the horse.”
I believe this is our situation when we are building software for complex problem domains like human health.
As is our wont, we gather requirements to decide what to build. We believe users know what they want. Requirements understood that way are not requirements. They are expressions of what somebody thinks what they want. The probability of building something useful with such requirements is low. Worse, it pushes us into situations, where we are just riding horses over which we have no agency.
The hardest task of building software is deciding what to build. And more malleable software gets in the age of cloud and mobile, harder that tasks gets.
I like closing the daily rings on my Apple Watch. Had someone in Apple’s design team cared to ask me, if I would like such a thing, I would have said no. I liked counting steps, but not much else. I had cycled through a couple of Fitbits and a Garmin watch. Then maybe in an attempt to look different from the madding crowd, I settled on an old analog watch for a bit. After that broke down, all I was looking for was a fancier step counter. I had no idea about the utility of those freakin’ rings. We don’t know what we want until we see it.
We have concepts like person centered approach to tide over this seeing vs. knowing chasm. I am afraid that may be one of those fast galloping horses from our story. Because following such concepts absolves the builder from having their own vision for the solution. But we know that the best tools come from aligning the builder purpose to the human purpose. You can’t build an Uber or AirBnb by polling your users.
Clayton Christensen urged builders to focus on learning “how to hear what your customers don’t say”. By understanding what prevents someone to make progress. That, by knowing constraints, not asking for requirements. Yes, the same Christensen who wrote Innovator’s Dilemma and coined “disruptive innovation” theory. He didn’t think disruption mechanism explained how to innovate. He often lamented misuse of the term disruption — “to mean anything that’s clever, new and ambitious”.
He proposed, to innovate, builders should understand jobs-to-be-done. Christensen wrote that a “job” is the “progress a person is trying to make in a particular circumstance”. He emphasized understanding the “circumstance”. He cautioned against “functional, social and emotional” dimensions of jobs and circumstances.
Early on in my career, I was once tasked to define requirements for a system to match patient cohorts to clinical trials. I started interviewing researchers and data concierge teams. They told me everything about what they were doing. And what they needed fixed — quite animatedly. I got details. In fact I was drowning in them and getting frustrated. The principal investigator of the protocol, perhaps sensing my struggle, sat me down one late afternoon. He drew on paper how he resected samples in a cancer surgery and how they were used in cancer research. He hooked me up for a live tour of their tissue bank. Those people showed me how they bank samples. Suddenly, I wasn’t worried about getting definitions of data elements right. I felt I knew about ‘morphology’ and ‘distal margins’ at a much deeper level.The frustration started ebbing gradually. I learnt jobs-to-be-done and discovered constraints people faced in doing their jobs.
More importantly, I developed purpose. I understood users’ purpose. My job was to propose ways to align those — not gather requirements.
The other thing about “jobs” is that they never change. The patients want to get healthy. The physicians and researchers want to extract better signals from real world information. Human purpose often stays the same. Only culture and technologies change. And as a result, the constraints people face to make progress keep evolving.
This episode I just described happened in 2010. Since then, cloud and mobile have happened. Microsoft came up with the original concept of shipping ‘good enough’ software. They tried to learn by shipping. Remember those yearly windows updates — good times!! Cloud and mobile platforms have put that concept on steroids. Software in our hands is subject to constant change, at a Moorean pace, either to satisfy new uses, or when it outgrows the hardware. User constraints also evolve faster than ever in response. As a result, understanding and solving for user constraints is not a discrete event. It has to be a constant iterative process.
In terms of technology changes, we now have those metaphorical fast galloping horses, coming at us every month, every week, even daily. It is hard to not get distracted. There is a temptation to hop on one to go someplace meaningful. But as I have discussed before, it is never been more important to view technology as means to an end. And means only matter after you have an end. So, let us not give up on our agency on solving for our own ends.
It is similar to how active investment managers try to look for alpha. They have to compete with passive market indexed funds. What do they do? They focus on discovering sources of alpha. Alpha is the excess return over the market indexed return.
You may be diligent in following the social proof of the market in backing the right fast galloping horses. You may be current on latest “digital health trends”. But if you do what everyone else is doing, you will get market indexed return at best. Which isn’t very good for digital health, I’m afraid. You have to work much harder to discover sources of alpha.
I have argued earlier that digital health has struggled because we haven’t built the right things. We remain stuck in a logjam of well-intentioned pilots, PoCs and MVPs. We resort to gathering requirements to ship something out on time. I think it is time to focus on a much more consequential risk — the risk of building the wrong thing.
We have to begin by understanding jobs to be done. We have to prioritize human purpose, and understand constraints preventing users to make progress. And we need to build cyclical loops for discovering and solving user constraints iteratively.
We often worry about getting disrupted — rightfully so. We see those fast galloping horses and get anxious. Don’t ask them anything. Just focus on creating alpha for your users. We will be fine.
