This piece blah blah….
Do More with Less
How Incremental, Evidence-Based Approaches Streamline Digital Development
When it comes to the development of digital products such as web and mobile apps, many of us harbor a potentially hazardous set of impulses. We get an idea, make a plan to see it through, then put our heads down and power through that plan, never looking up for confirmation that our intended users are on board.
Luckily, over the past 30 years, a variety of processes have emerged to temper these moonshot development impulses. Each of these modern processes, from Agile to Lean, has its subtleties. But they all embrace incrementalism, or development in phases, wherein each phase is informed by evidence secured in the previous phase.
In this paper, we’ll take a high-level look at how, when organizations embrace these incremental, evidence-based processes, they can develop digital products more efficiently through early validation efforts; focused, testable first versions; and increased, iterative user testing.
Validate a Core Offering Prior to Development
Incremental, evidence-based product development approaches ask that we regularly assess our efforts and, at every turn, look for user feedback that indicates we’re on the right track. Interestingly, this dependency on evidence plays a role in modern development even before a single line of code is written.
“Before you start developing, you should make every effort to validate product-market fit,” says Kevin Spanbauer, co-founder of the Minnesota Emerging Software Advisory (MESA), an organization of experienced software professionals who offer Minnesota startups pro bono mentoring. “You need to know if people want your solution,” he adds.
Unfortunately, many pre-product entrepreneurs skip this step, says Spanbauer. “They feel that they themselves would use the product, so they never stop to confirm that anyone else would,” he says. It’s a risky gamble in the digital product development space, where costs are high and resources are almost always limited.
How might we mitigate these risks and validate our products before investing a lot of money in technical development? Startups and other organizations have found a variety of low-cost ways to validate their products’ core offerings pre-build through the use of surveys, design-only prototypes and interest-monitoring landing pages. For many organizations, though, the trouble comes not in validating the core offering, but in defining it.
“When it comes to prioritizing a core offering, we all have the same problem,” says Brian Krohn, founder of Soundly, a mobile application that reduces snoring through voice-activated, game-based therapies. “We all say that our product offers users A, B and C. When we’re forced to pick just one, we struggle.”
It’s a struggle that Spanbauer regularly encourages his MESA mentees to push through early in the development process. “Focus is the one thing you have to have,” he says. “In software, you can’t afford to boil the ocean.”
Build & Test the Core Offering First
Identifying a core offering may be difficult, but it’s worth the effort. Not only does it define what needs validating pre-build; it simultaneously creates the priority and scope for the first version of a product.
“Once you pin down that core offering, that core function,” says Krohn, “you know what you have to build first. Everything else, all the other features, become ‘nice to haves’ that you can add on later.”
Concentrating on the core offering in the initial build of a product not only prevents scope creep and overinvestment; it also results in first versions of products that are easy for users to assess.
What you build first should be something that a user could look at and say, ‘Ah-ha, I see the value,’” says Krohn, “because that is precisely what you want to test for before you spend more money.”
Put another way, the better the first version is at illustrating the core offering, the more informative the user feedback we receive about it can be. A commonly used example to illustrate this idea compares skateboards and wheels. If we build and show users a wheel, their feedback will be all over the map. But if we build and show users a skateboard, they’ll be able to assess its value and indicate whether or not they want it.
“It’s the minimum viable product, or MVP approach,” says Spanbauer. “You’re trying to invest minimally but still deliver something a user would pay for. That’s what it’s all about.”
Test & Pivot More, Plan & Build Less
Building in an incremental manner comes naturally to us. We build one piece, then the next, and then the next. But if we aim to embrace a modern approach to incrementalism, we must do something that doesn’t necessarily come naturally to us; we must seek out feedback from others.
Unfortunately, most of us are more likely to make our own plan and see it through than to reach out for feedback along the way. It’s a propensity that Spanbauer has seen more than once. “Everyone is ready to build these great, big products,” he says, “even before they have a single customer.”
Krohn has seen and experienced the same thing. “The impulse is to build, build, build—then launch your product out into the world and cross your fingers,” he says.
What’s the problem with this inclination? First, it often results in products full of features and functions that users don’t value. “We’re wrong a lot,” says Krohn of our straight-out-of-the-gate beliefs about user wants. “What’s important is to learn how and why we are wrong quickly.”
How do we learn quickly? Frequent user testing, says Krohn. “You need frequent user feedback so you can pivot incrementally as needed,” he says. “That’s what keeps products on point.”
These frequent interactions with users also control development costs. “Think of it this way,” says Krohn. “You can build ten features into your product, then learn post launch that you were wrong on nine of them. Or, you can develop one or two features at a time and be wrong on just one or two at a time.”
Just as frequent product testing reduces wasted development costs, it also reduces wasted planning efforts. When we build and test our products incrementally, we spend less time planning for outcomes that may never occur.
“You fret less about decisions that don’t matter,” says Krohn, “because you come to learn that user feedback is constantly causing your plans to change anyway. After all, no plan survives an encounter with a customer.”
The tactics and efforts outlined above, as well as countless others like them, would be of less interest to organizations today if digital products were inexpensive to build, or if we all had unlimited time and resources.
Unfortunately, neither is true. Digital products are expensive to develop, and the dollars and time available to build them are almost always limited. The good news is that when we embrace these modern, incremental, evidence-based approaches—which one could argue are really just the centuries-old scientific method in disguise—we can learn more and develop better digital products with greater efficiency than ever before.
—END—