Pushing Products Down One’s Throat

My previous post discussed how the industry of PC software has evolved based on the analogy of physical goods; I argued that we have been using the wrong metaphor in referring to software-based offering as products. I also pointed out how advancements in technology have removed traditional constraints in a way which is gradually changing the software medium to introduce what I referred to as “streamed software”.

And yet, for the most part, too many companies choose to adopt a highly conservative engineering-thinking approach when they address the challenge of developing software. The mantra of “if you build it, they will come” has been the prominent one, as I can attest through many startups and large companies I either worked at or worked with. Too many founders start developing the product with only a faint idea of what customers really want. they will typically talk with few potential customers before they raise some money but very quickly the company shifts most of its energy to R&D. The conventional thinking has it that first you build, then you prove it works by attracting few early adaptors, you raise some extra money and only then you start scaling by adding people in product management, marketing, sales etc. etc…. at a point where you are already too much invested, financially and mentally, in your own ideas for you to easily change route.

Well, the problem is that far too often you do build it and nobody comes, because nobody cares and it is then that you realize you are facing a ‘market-product fit’ which a nice way to say that you were trying to push your product down your customers’ throat, only to realize it’s not as digestible as you imagined, and that customers tend to throw it up. I believe we owe a big part of this mishap to grounding our thinking in the framework of traditional physical goods; and i’m not trying to say that the market-product fit problem is unique to software, on the contrary — it’s software with its elasticity and flexibility that provides us powerful tools to break-away from the “inside-out” engineering-driven approach, in ways that physical goods can’t, into new methodologies that could greatly improve our ability to build things that people will actually use and love.

Lean and Mean

Few methodologies and bodies of knowledge have been developed over the last decade to address the challenges of early-stage companies to successfully innovate. One such methodology has been underlying the ‘customer development’ and ‘lean startup’ movements, created by Steve Blank and Eric Ries, respectively. There are different nuances and an important level of details to each of them, but they do share the common understanding (as stated in the ‘Customer Development manifesto, Rule #1’) that

There Are No Facts Inside Your Building, So Get Outside

Blank and Ries, both realized that the challenges facing a startup, trying to build a product from scratch, are very different from those of a mature organization (though I would argue, that in some contexts, it is also relevant to enterprises) and claimed that most of startup’s energy should be investment in 1. articulating hypothesis 2. building experiments to test them 3. test them with customers to achieve validated learning 4. adapt the hypothesis to what was learned. 5. iterate until reaching the right market-product fit. Ries has further coined the term Minimum Viable Product (MVP) as a way to translate the step of ‘experiment building’ into the practical aspect of product management and software development. Unfortunately, while the theory behind both movement is solid, it didn’t succeed, in my view, to fix the bias of ‘engineering-first’ of most startups and MVP has became one of the least-understood and most-abused term in the history of software, often translated into ‘let’s build a buggy low-quality product, because we will have to rewrite it anyhow soon’.

Hiring Products to Do Jobs

While the intuition of ‘customer development’ is right, it still falls into the pothole of the product metaphor as is evident by the ‘P’ in the MVP acronym. A different theory which emerged from innovations studies does a better job, in my opinion, to broaden the lens of view of this topic. This theory is called “Job To Be Done” (JBTD) and was developed by Harvard Business School professor Clayton M. Christensen. Christensen, who has regrettably passed away this year, is mostly known as the author of the best-selling book ‘The Innovator’s Dilemma’. Customers don’t buy product, so the theory goes; rather they hire them to get a job done. The word ‘hire’ is important in this context as it suggests that the value customers are seeking is bounded in a well-defined context and that ‘the product’ is no more than a means to an end — a temporal utility to fulfill the job.

More importantly is Christensen’s definition of ‘what is a job’. A job is not a task, but a multi-dimensional challenge a customer has, which includes not only a functional aspect but also social and emotional ones. Getting a job done, means allowing the customer to make a progress with respect to this challenge in a way which addresses all those dimensions. So it follows, that the most critical mission of any company trying to develop an innovative product is to ‘discover’ and ‘reveal’ the job of the target customer. One of the examples given to illustrate JBTD is with ‘The Milkshake Dilemma’. A case-study of a fast-food chain trying to figure out how to increase their sales of milkshakes. I will skip many details for the sake of brevity, but what applying JBTD method revealed was that people were buying (or ‘hiring’) the same milkshake for very different reasons. They were those buying milkshakes before 9am as a nutrition supplement for breakfast on their way to work. That milkshake was competing for the same job with bagels and with nutrition bars. Then, there were those who were buying the same milkshake at afternoon — often dads seeking some bonding time with their children and making progress on the ‘dad of the year’ self-job. Now this milkshake was competing on a different job with things like a visit to the toy store, or watching a movie together on Netflix.

I like JBTD because it provides a non-traditional way to think of what we build and more importantly, for what reasons. When you focus on the ‘job’, you are forced into thinking beyond the functional dimension and to address also the the social, psychological and emotional ones and that in turn allows you to think of what you do in terms of an answer to a question: ‘why the customer would hire it and for what job’; that often makes your code really a sub-product of the bigger value that you need to build for the customer.

Something to be Learned from Designers

Lastly, no other school of thought has perfected the concept of solving a multi-dimensional problem with a strong sense of the user in mind, then has been the case with the practice of Design. The idea that a design-based approach can be applied to almost all aspects of life, whether these are problems in education, organizations, agriculture, the job market or the hi-tech industry has now been widely accepted by of the biggest companies in the world. ‘Design Thinking’ or ‘user-centered Design’ is a method and a framework that was originally developed by the design firm IDEO; at its core is the notion of empathy, which anchors the process of innovation in deeply understanding the experience that the users (those whose problem we’re trying to solve for) have, what is their struggle and what barriers could be lifted for them in a way that provides usability, delight and purpose. It then follows a very methodological and practical process of observations, ideation, prototyping and testing to develop that experience for the user. IDEO General Manager, Tom Kelly, gives a marvelous case-in-point in his story of how to design a toothbrush for children.

Thinking From the Outside In

These three methodologies I described stem from different faculties; the first emerged from the start-up Silicon Valley meetups, the other has been developed in the traditional business school corridors while the third one is rooted in the practices of design schools and agencies, but they all share the same core idea of the need to think from the outside in. They have all made a huge impact on how modern companies have started approaching innovation, putting the user as a starting point and have definitely contributed to the importance of User Experience to the success of many of the new unicorns emerging in the last 5 years or so. Yet, I think that this kind of thinking is still far from reaching the main stream of software development practices. What I see more often than not, is that the startup CEOs and Product leaders in the best-case may have some knowledge and vague appreciation to these ‘winds of change’; in the worse case, assuming they heard of them at all, they would pay a ‘lip service’ by doing no more than using them as buzzwords (“sure, we think UX is very important, so let’s talk about how big this button needs to be”).

There could be all kind of reasons why this is the case, but to me, a big part of it still lies in the fact we have chosen the wrong metaphor of ‘product’ to govern how we develop software and that with all the talk about ‘customer-first’ approach, at the end of the day, if you reverse-engineer how organizations work, little has changed since the old days of the 80’s where software products were envisioned and planned as a discrete utility/tool that provides a functionality to a well-defined single-dimensional problem, no matter how much evidence we have that people just don’t pursue their ambitions or consume the means to achieve them this way.

In my third and last post of this series, I will try to suggest a different perspective for software development. Until then …