How Your Product Development Model Impacts UX Strategy
Published: May 20, 2013
Putting together a cohesive and successful product development process requires some thought about how much you plan to involve customers. This, in turn, drives your team’s level of commitment to user experience, and how you’ll shape your approach to user experience.
In this article, I’ll identify, describe, and discuss the three predominant models for product development. Often, whether in very large organizations or startups, there is no clear and deliberate choice of development model. In fact, in very large organizations, there may not be any single person—or even a single committee—who can determine what method to follow. Shared responsibility, turf battles, and resource availability—including talent—may present insurmountable dictatorial hurdles. However, recognizing and understanding the options—whether by design or happenstance, can help you to maximize the good and minimize the negative aspects of each method.
Model 1: Invention
An old idiom states that “necessity is the mother of invention,” but if we look at the development efforts within many technology companies, we find that it’s just not so. Patent filings are replete with inventions that are seeking a need to fill, just as many unsuccessful solutions search for the problem they were meant to solve.
Invention—an old-school model that was predominant at 3M and a host of technology companies—is still at the forefront of what most people think of as innovation. Lots of smart folks—be they chemists, biologists, engineers, or physicists—are working hard to prove theories and successfully develop new technologies and combinations of technologies, often in collaborative environments. Killer stuff. The stuff that so much of our mechanization and technological advancement is based upon. But this isn’t necessarily innovation as much as it is invention. And this is not a particularly smart way to work.
Jared Spool recently tweeted, “Don’t confuse innovation w/invention. Invention is making a novelty. Innovation is making value.” While Jared may be taking liberties to enhance contrast, his point is quite valid. Jared further tweeted:
“This was the realization I had a little while back: Invention is important. It’s about creating something in the world that has never existed ever before.
“But that’s different from innovation. Innovation is about adding value to the world that didn’t exist before. Turns out, you can innovate without invention.
“In fact, some of the best innovations came by borrowing an old idea and applying it in a context that no-one had before. The value comes from the new application of the old thing, not from creating something new.”
When we talk about true innovation, it must have a purpose, and it must have an application. True innovation adds value as it enters and influences the marketplace. Inventing things because we can, then seeking a purpose or customer for our invention is a bit like fishing with a pistol. It’s a high-risk, low-probability proposition.
In one of my early business classes, a professor quoted a statistic along the lines of: “Only 10 percent of all new product introductions survive the first three years.” (His attempt at defining success.) The specifics of that statistic aren’t as important as the general notion of the failure that most new products face once they’re in the marketplace. Consider the resources expended on the development and launch of the other 90% of products that companies introduce.
Why did they fail? Many products fail because they don’t do what their makers promise, or they aren’t well marketed, but I posit that a huge percentage of the products that get introduced into the marketplace are complete misses. Customers flat out don’t want these products because their value propositions don’t meet their needs, so they aren’t profitable.
This is not to completely invalidate the invention model. I’ve worked on plenty of successful initiatives that began with this question: “We have this capability; what can we do with it?” If you have a product capability, you have a fiduciary responsibility to direct that capability toward a return on the cost of invention. But if you’re starting from scratch, this method does not present you or your organization with the highest probability of success.
Model 2: Blending Business and Customer Needs
It was just a few years ago that I rallied a team of managers, and we set out to do things differently. What we experimented with was looking at an area of interest and, we thought, opportunity, and putting together two separate strategies. One of the strategies specifically addressed a need the UX group was seeing in the marketplace. It was customer centric. We were asking broad questions of our customers and looking for specific opportunities, as well as problems to solve. Our user experience group was conducting its own form of competitive analysis, which was design- and use-centric. This varied from what the product and business group was doing because it focused upon users’ needs and how various competitors were addressing and satisfying those needs.
Meanwhile, the product managers (PMs) continued working as business owners to formulate a strategy that covered these fiduciary responsibilities. Their efforts included competitive analysis—though this focused more on core business concerns, including costs, returns, and feature-to-feature comparisons. The PMs also had access to and made great use of site metrics.
While both groups were analyzing quantitative data and trends, driving while looking at your rear-view mirror isn’t always optimal. The qualitative nature of our UX inquiries helped provide insights into the reasons why there were product gaps and made those gaps visible. But that’s not really enough. Both the UX group and the PMs were responsible for articulating a clearer and more far-reaching vision: what’s next; what could customers use that they can’t yet imagine?
As we formulated both our customer-focused and business-focused strategies, we stopped short of creating any final development documentation. At the draft stage, we pulled the Product Management and UX groups together, as well as Engineering. Working with a group of twenty plus in a room isn’t optimal for efficiency, but we were trying to accomplish a couple of things: First, we wanted to blend our separate knowledge pools and strategies into a single shared vision. Second, we wanted the Engineering group to have insight into where we were going with our designs and provide their insights to us. Often their first reaction was, “No, we can’t do that.” But in an age when there are fewer limitations in software, we were more interested in hearing the answer to the question, “When can we?”
As the team discussed various capabilities and debated our different perspectives on how to accomplish our goals, the conversation occasionally became passionate. But when we came to an impasse, we always seemed to have data to better inform our decisions—and if we didn’t, we reached out to get it. For the most part, while everyone in the room had an opinion, we tended toward relying on data, expertise, and skating within our lanes to resolve issues.
Model 3: Putting Customer Needs First
The third development model, which is very scary for some of our partners, involves placing the responsibility for the vision and strategy primarily within the UX group. At a minimum, this means using our understanding of customers as the primary foundation for a product strategy. This is customer-driven innovation. This approach involves using critical insights from usability testing, contextual inquiry, and co-design sessions, but it also relies increasingly on molding a synthesis of that data into a product vision. When considering longer-term vision, it puts substantial pressure on the staff to predict the future. Though a long-term vision may help prepare us for change, it’s direct benefit in product design strategy is often dubious. So much can change so quickly in this trend-driven digital world.
In a customer-focused company, there is dedication to providing solutions to meet specific needs and determining the means by which a company can profit from them. The offerings you put into the marketplace need to be the direct outcome of a company’s mission. If you’re familiar with Peter Drucker, you’ll recognize that, while it is not a company’s mission to profit, profit is a necessary outcome of delivering offerings that are consistent with its mission.
This does not mean that we can offer products and just hope to profit later—like so many dot com firms of the 1990’s. But it does mean that the profit model shouldn’t force the form of our product offerings. Instead, profit should be an outcome and augmentation of delivering product offerings with minimal compromise of the final benefit to our customers.
The benefit of this perspective is that profit doesn’t blind us to the real issue: do customers want our products? Customer needs drive product strategy and the design process. The variables that we should then be concerned about look a little different: Did we interpret too much? Are we looking too far down the road? This is where the minimum viable product (MVP) concept from lean development approaches becomes advantageous. MVP is not a new concept; it’s what we meant our quick, iterative prototypes to deliver before they became bloated and slowed by the angst-ridden demands of managers and committees. Getting our ideas in front of our target customers early and often is critical.
How Do These Methods Play Together?
These three models of development represent a progression toward customer sensitivity and focus. The last of these methods acknowledges a new level of technical maturation: that we now have sufficient technical capabilities to make a lot of things and make a lot of things happen. The models represent three rather distinct approaches, but I don’t think of them as absolutes. Much as big design up front and Lean UX represent the outlying points in a continuum, there are good blends of these approaches in between the extremes.
Further, in a large, complex organization, we often don’t have the luxury of choosing just one of these methods. It’s quite likely that all three of them will be in use somewhere within an organization. The trick is to identify the model that accommodates the needs of a particular project and build a strategy around it. If we can evolve our development model, we can increase our chances of success.
In a smaller organization, resources will likely drive the development model. Is there sufficient funding? Does the acumen for customer sensitivity exist? Is the talent already present as a team formulates its strategy?
If we look specifically at startups, we typically see a seed idea—often based upon a founder’s introspection. The idea or concept is prototyped or realized only if there is sufficient technical capability. If its realization requires funding, a company must inject at least a minimal financial strategy. With investors pushing for a quick launch and a fast-burning fiscal fuse, research, prototyping, and user knowledge are often in short supply. As a consequence, a startup may race toward an ill-advised, large-scale launch. By then, it’s often too late for customer-centric considerations. Game over.
What Is the Future?
More data—but perhaps not in the form you may be thinking of. The promise of big data will do a lot for us in stable markets. Bezier projections of quantitative data are valid, but don’t logically anticipate the specifics of market disruption. With startup models promising huge returns, the disruption of market leaders is a recurring mantra and an ever important consideration in that world.
While these are influences that we cannot control, we can work to incorporate them into our strategies and anticipate their impact. Two of the best places for us to invest our efforts is in developing a better understanding our customers and building a development process that minimizes waste. One that ensures that, when we fail—and we will often fail—we will learn.
Culturally, we need to build organizations that understand this learning process, so don’t hold tight to the expectation of our having everything figured out in advance. If we want to innovate, we will sometimes make mistakes and design the wrong solutions. As a result, there will be some waste. But these small amounts of wasted effort can lead to big learnings that will more than offset the waste. And this kind of waste is nothing in comparison to the waste that results when companies introduce misdirected and unwanted products.