Hypothesis-Driven Development and the Generalist Superhero

‘Tech’ — Where Do I Fit in?

If you pay attention to “business,” you’ve probably noticed the world’s changed a lot. The star analyst is now a data scientist, a private equity associate is tasked with reinventing a company’s IT instead of engineering its finances, and the marketer is now a “growth hacker” running A/B tests.

Regardless, the exciting thing about “tech” is that it no longer takes a corporate empire to make a billion dollars — Instagram had just 13 employees when it was acquired for that amount. While most startups need to scale to somewhat larger organizations for that kind of outcome, the work of tech usually has more to do with getting the right team of seven to 12 people together and giving them the autonomy they need than it does with building a large command and control organization.

This is where you come in.

The digital applications these teams build change the way we live and work, amplifying us. They may amplify our recreation, like Instagram, or take the repetitive grunt work out of our jobs, like the way your calendar application helps you find the best time for a meeting. A more nerdy, more forward-looking explanation is that we’re becoming a distributed intelligence, distributing part of our intelligence to automation.

And being a generalist who’s not afraid to dig into new topics is now kind of a superpower.

Do I Need to Learn How to Code?

I have a deep and abiding interest in how to equip interdisciplinary generalists to do high-impact work in tech, work that moves the needle on product and business model economics. In the tech world, we sometimes call these “traction roles.” In the MBA world, we call it “general management.” For me, the basic test is whether someone in the role has meaningful responsibility for driving revenue while investing in certain costs to make that happen. The most common job title in tech with this responsibility is “product manager,” but it’s also the job of entrepreneurs and, increasingly, consultants and various other types of managers.

I’ve seen fantastic growth into these roles on the part of both non-technical generalists as well as technical specialists. For the non-technical, their big blocker was answering the question, “Do I need to learn how to code?”

Learning to code itself wasn’t the blocker — the blocker was that they had trouble connecting their coding to the work they wanted to do. Ultimately, getting over that blocker has a lot to do with creating a testable point of view on what they wanted to happen, and then working from there to find the technical facilities to make that happen. In practice, this meant knowing how to learn just enough about the technical matters at hand to focus their ideas and facilitate technical collaboration on them.

As I often tell general management students in my coding classes: “You don’t have to know everything. But you have to know how to know everything.” And so far, so good — to date, I’ve seen MBA students build everything from a recommender system for second year electives to a machine learning app for product managers to analyze customer complaints.

2 Problems and a Solution

I’m convinced practice can get much better for more practitioners, both for non-technical and technical types. However, I’ve noticed two big problems in the real world of digital.

The first problem I’ve observed has to do with onboarding generalists. A lot of the really great on-ramps for being some kind of manager or leader in tech emphasize prior experience in some technical discipline, like coding, data science or design.

Second, most of us want a go-to practice, something we’re all in on — Design Thinking, Lean Startup or Agile, for example. However, all of these approaches have areas where they perform well and others where another practice is a better fit.

What I’ve learned is that Hypothesis-Driven Development (HDD) does a nice job on these two big issues, in particular for generalists figuring out where they need to upskill for tech. Like Agile, Hypothesis-Driven Development is a loose body of work with a central purpose and set of principles. Central principles for HDD are to:

1. Explicitly focus your intent, which is a longstanding feature of product design.
2. Link that intent to specific observations for making specific inferences, which is a longstanding feature of science.
3. Make crisp decisions based on the above with a focus on iteration and small batches, which is a longstanding feature of Lean and Agile.

In practice, I’ve seen this deliver well both for the work of product teams as well as MBAs who are, at the same time, pairing that work with surgical upskilling.

Progressive Adaptation

What I love about HDD is that it calls attention to what all the prevailing disciplines have in common and how that anchors back to a shared point of view on outcomes. It helps generalists of whatever sort engage with their peers around a shared view of how they’ll test their way to a good outcome. And importantly for a field that changes a lot on the margins, it helps lifelong learners think about where they’re headed next.

In tech, it’s generally frowned upon to use the term “best practices,” and the reason is that we’ve learned there’s so much variation from company to company, product to product, and even team to team that the idea there’s a single approach that will always work often does more harm than good. HDD offers a useful solution to this in that progressive adaptation is built into the core of how it approaches the work of teams.

Make the Lemonade

HDD is not about “analysis paralysis” and waiting for complete certainty before taking action. If the age-old take on new ventures is something like “Let’s build a lemonade stand,” then HDD just amends that a little to something like “Let’s build a lemonade stand at the intersection of Fourth and Main this Saturday, and if it makes over $50, we’ll consider that a win.”

Whether or not you’re “technical,” to get reliably good outcomes you need to get in the habit of working in discrete batches of testable ideas. In practice, that means defining a testable view of the economic result you want for your product or company and being able to cascade that to facilitating discussions with your team about which programming language to use, where you might find wins with machine learning, and how to automate your product pipeline.

At the heart of HDD is acting intentionally. Particularly in the highly uncertain environment of digital innovation, a company needs some kind of anchor point for what it’s trying to achieve. Without this, a company can easily have a number of beautifully executed initiatives that add up to an economically irrelevant mess — and this happens all the time.

Alex Cowan is author of Hypothesis-Driven Development: A Guide to Smarter Product Management (Cook & McDouglas).