How do product development teams know whether they are creating value or just cranking out features? Widen’s VP of Product Development Deanna Ballew argues that it’s time to rethink the way we find, diagnose, and solve problems in the pursuit of value.
Software companies often conflate features with value. They race to solve problems with solutions that are technically impressive but don’t necessarily benefit anyone.
I think it’s time to reexamine the way tech companies find and solve problems. It starts with accepting that value is in the eye of the users, not the innovators.
My goal here is to discuss how product development teams can step outside their limited viewpoint. We can deliver the most value when we find, diagnose, and solve problems that would normally remain in our blind spot.
Learn More: The Key Ingredient to Driving Successful Digital TransformatioOpens a new window n
Symptoms vs. Diagnosis
An underlying assumption in the tech space is that problems are pretty obvious. Maybe we have firsthand experience with the issue, or maybe we just ask the customer about it. If only it were that simple.
Think about a trip to the doctor. We don’t tell the doctor about our problem. She asks questions, and we share symptoms — not always that clearly. The doctor’s job is to identify the problem. In our world, users are the patients, and product teams are the doctors.
In the consumer tech world, though, the innovator is more likely to experience the symptoms personally. For example, an innovator who spends all day in a room on the internet might experience hunger, boredom, and social isolation. So, maybe he’ll invent a mobile food delivery app, an iPhone game, and a social networking platform to solve those problems.
But in B2B software, we have to find symptoms inside unfamiliar industries, work cultures, and job roles. For users, the symptoms of a problem are not easy to communicate, in part, because the software is unlike anything people learned to describe and discuss as a kid. Often, we need to witness patients in the moment of pain.
Learn More: Taking on the Patching and Configuration Crisis: 3 Critical Steps for 2020Opens a new window
Well Look at That
At Widen, my team and I make digital asset management (DAM) software. It’s a sophisticated content library that powers visual marketing experiences. Eighteen months ago, my team and I performed field studies where we spoke with customers at their offices and watched them use our software. We noticed that when they uploaded content into our system, they checked, double-checked, or even triple-checked that the metadata was entered correctly. They seemed unsure if their uploads had worked as intended. Those were symptoms that users had never communicated to us.
Technically, the upload process “worked†properly, in that if you clicked the upload button, the files would be stored in the DAM system. The issue was how users felt while performing the task. In any business, being confident and comfortable with software is valuable. It affects whether organizations adopt the software at all.
The field studies showed us symptoms of the real problem: an upload experience that caused uncertainty and clashed with users’ expectations. We decided to benchmark our upload process against social networks and photo apps like Flickr. Many of our users are not trained DAM administrators, but they know those platforms. Maybe they’d prefer a similar upload experience that minimizes uncertainty?
Based on our research, we developed a new upload process and introduced it alongside our “classic†experience to give users a choice. We wanted to see if they’d utilize the new process. The new upload experience is at roughly 50% adoption five months later, which means we still have work to do. There will be a version 2 and version 3 that aim to bring adoption above 80%, at which point we’ll feel good about the perceived value we’ve delivered.
Learn More: How Does Outsourcing Help Reduce Software Development Costs?Opens a new window
When are we Finished?
Value isn’t created the day you release new code. Until software came into play, businesses operated on the assumption that products could be finished. You can’t buy a “beta†version of cereal at the grocery store that will taste and look different in three months. But in software, launching a new anything is like dropping a puck. The game has just begun. Quantitative researchers follow and report the action like rink-side announcers, tallying up points that speak to user value.
When we launch a product, we’re just testing our hypothesis about how to solve the problem. That’s it. The first version of our solution is probably flawed, as we’ve learned while iterating Widen’s upload process. And the risk of unintended consequences — of crashes, slow speeds, and frustration — are high. But we aren’t “finished†until our users embrace the change. Users decide when the job is done.
Unlike cereal makers that can’t download an update to the box, we iterate. We’re not chasing novelty — we’re changing the way someone does their job. That someone cares more about uptime, performance, and the quality of changes rather than the pace of change. The point is not to “disrupt†their work (not often, at least).
It has Enough Names
The ideas in this article are popular in theory but surprisingly rare in practice. Whether you call this bundle of ideas progressive delivery, iterative development, user-centered design, or agile, it shares the same intention. That is to create value while minimizing risk.
When I watched our users upload files, I didn’t expect to find symptoms of fear and uncertainty during uploading. And maybe my colleagues in other departments underestimated what it would take to craft and iterate a solution.
The future of B2B innovation is to find new and revelatory signals of value in usage data, observations, and new sources. We haven’t even come close to tapping all the ways we can examine the human experience with technology. The search for value begins when the race to release features ends.
Ultimately, we don’t get to decide whether our innovations are valuable. The user does.
Let us know if you liked this article on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!