Disregarding the Status Quo
I have a problem with Requirements. “Requirements,” in the common vernacular of software development, are not requirements at all — they are constraints. Sure, understanding technical and behavioral assumptions is important, but they are a means to an end, and can be detrimental to creative solution ideation if they are blindly accepted as the only path forward.
However, the phrase I despise most is “table stakes.” These are like requirements++. “Table stakes” are framed as do or die requirements.
Requirements for what exactly? Requirements to copy what everyone else is doing. No thanks.
What about the pursuit of ideas that blow up the status quo — to find a better way to meet a user need or solve a business problem?
Requirements and table stakes are a creative wasteland. An uninspired cognitive modality where nothing grows and gratifying, high impact results are forever out of reach.
Try to stop thinking of requirements altogether, and instead start thinking about product along two fundamental dimensions:
Dimension One: Needs
To understand a problem, first weneed to know if the problem is an unmet or unrealized need.
A. Unmet Needs
Unmet needs are those a user is well aware of and can easily describe. They are a close cousin to functional bugs.
Meeting unmet needs is about improving upon that which has already been created. It is about building a better email client, fixing janky search ranking or decreasing latency.
Most of us spend the majority of our time operating in this realm, as it provides the most career opportunity and the least amount of risk. It is about taking market share from inferior products. Moreover, while it can lead to market growth, it is not about market or category creation, which is what makes it so attractive.
VCs fall over themselves chasing after “total addressable markets,” which is business speak for the aggregate value of existing solutions in a particular problem space or industry.
Plenty of innovation occurs in this realm, often in the form of small, iterative improvements. I call these evolutionary innovations. Trello is an example of evolutionary innovation. By applying a Kanban design model to the ubiquitous todo list, Trello essentially reinvented the category. While it aims to meet the same needs of those before it, in design execution it evolved the category into something far more flexible and useful.
However, Trello’s biggest innovation in the space was the decision to interoperate with, rather than compete with, all the other apps one uses in their daily workflow. Perhaps best described as a business model innovation, it realized that one size never fits all, and everyone has a set of tools they already use. Instead of seeking to displace those tools, Trello chose to narrow their focus and carve out space for itself without requiring users to abandon the tools they love.
B. Unrealized Needs
Unrealized needs are those that users may not even be aware they have until they see and experience your product. They are inventions that fundamentally change user behavior. Moreover, when users discover them, they become part of the fabric of their lives — so much so that they can barely comprehend life before it. These are transformative innovations.
Successfully meeting unrealized needs is hard. Often (but not always) there is no market to go after because it does not yet exist. Smartphones fall into this category. Specifically RIM’s Blackberry devices, and later Apple’s iPhone.
While one can argue that these are both examples of evolutionary innovation (after all, isn’t the smartphone just a more advanced cell phone?), I would say that due to the scale and magnitude of their societal and behavioral impact, they far exceed the relatively modest criteria of evolutionary innovation.
These products changed the world. Trello, as excellent as it is, will never have an impact of that magnitude.
Dimension Two: Customer-Inspired vs. Technology-Inspired Solutions
This second dimension defines the source of the solution.
A. Customer-inspired
If you get to know your users and observe or elicit their frustrations and needs, you will likely spot opportunities for improvement. At a minimum, the user will offer up solutions. If considered with the right mindset this can be a useful and informative aspect of information gathering. If however, we allow outside influences, including the user or competitors, to drive product requirements, the results will be little more than a slightly better mousetrap (more on that below). Often when speaking to users, they will ask lots of questions about your features and capabilities, and draw comparisons to other products.
This is extremely useful, as the nature of their questions reveals their needs. However, the more you can steer the discussion to problem sets, and away from features, the more you will gain a deeper understanding of their motivations and needs.
When they ask if you have feature X, turn the question back on them, such as “that is an interesting question, what is it you hope to gain with that feature, how do you imagine using it?”
B. Technology-inspired
While customer driven information is useful, it seldom leads to breakthrough solutions. More often than not the source of innovation is the enabling technology itself. Examples include leveraging mobile sensors, developing advanced machine learning algorithms to enable personalized recommendations, natural language parsing and computer vision to extract structured data, robotics to perform factory work and increase production. Technology, whether existing (like a phone sensor) or built, like a recommendation engine, is the creative conduit to an innovative solution.
In most cases, innovative solutions are at least in part technology-inspired. Moreover, the desire to leverage technology to solve a problem leads to improvements in the technology itself.
To give an example: recommending places to people that they would enjoy. Yelp and others attempt to solve this by showing users reviews of the place.
The problem, of course, is that those reviews are written by other people who have different tastes. Mobile sensors, however, tell us where people go, so by knowing where they go we know what they like. Since we know what they like, we can infer other places they will probably like also based on their taste profile derived from their location data.
However, if the precision of the location data is weak or inaccurate one runs the risk of creating false signals. We think you went to an upscale Indian place, but instead, you were next door at Dominoes.
To achieve the tech-inspired solution one must first increase location precision to the point that it accurately contributes to the user’s taste profile.
A byproduct of technology inspired solutions is that they lead to identifying even more unrealized needs. For example, the explosion of platform interoperability has opened up new areas of innovation that meet previously unrealized needs.
Did we need yet another messaging platform? The fact that just about everyone I know is using Slack seems to indicate yes. For Slack (and Trello and many others) the big breakthrough was interoperability.
Know your User
It is critically important that PMs, product designers, and engineers interact directly with users in their native habitat. It is a unique circumstance that cannot be artificially created where the full spectrum of needs (realized and unrealized) and solutions (customer-inspired and technology-inspired) can most easily be identified.
Problems vs. Features
With the above in mind, it should be clear why it is important to frame the problem instead of the feature. Before one can successfully define the “how” one needs to understand the “why” and the “what.”
If it is an unmet need, why is it unmet, and why does it matter? And what exactly is the problem not being met?
Once we understand the why and what of the problem, we can begin to work on the how by ideating technological ways to address the problem. We can form theoretical hypotheses. Then we can quickly test and validate which of these ideas will have the biggest impact in the shortest time with the least amount of effort.
But what about revenue?
In modern software development, this process of innovative solution discovery is often side stepped. When growth is the primary goal one’s natural instinct is to give the users the features they say they want — to gather requirements.
When a user mentions a competitor, we want to run a gap analysis to see where we fall short and the risk competitors pose in gaining valuable market share. But in doing so, we cheat ourselves of the opportunity to leapfrog the competition in new, technologically inspired ways that more often than not are more efficient, less expensive, and from the user’s point of view, simpler solutions.
Ignore the experts
Institutional outsiders have a unique advantage. Unlike the insider, they are unburdened by the shackles of deeply ingrained bias. The domain expert has been living in a universe defined by a set of presupposed rules and ways of doing things. They are not (generally) free thinking, so the requirements they gravitate towards invariably will be based on what they know or what they have seen others do, which is the status quo.
As technologists, we are in the business of inventing the future — of breaking the status quo with the innate belief that there is a better way, one that hasn’t yet been invented.
We consider the problem through a new lens. Our ideas revolve around the unique technologies we have developed or that live at the center of our lives. We are unencumbered by the creatively limiting forces of domain-specific bias.
While it may sound naive, the less we are willing to accept about the way things are currently done, the higher the likelihood we will think of new and more impactful ways of solving both unmet and unrealized needs.
Again, this is not to say that product designers should be ignorant of market dynamics and the actors involved. As stated previously it is invaluable to spend as much time understanding the user and their needs as possible. From there it is our job to prioritize those needs in order of importance and then develop new ways of addressing those needs by delivering capabilities they can get nowhere else. We need to find our secret sauce.
