Treat your software as a product

Uber and AirBnB are the poster children these days for disruptive business models, fundamental shifts in company strategy, and so on. There's a tendency to sensationalize these instances of technology-driven disruptors. We believe that innovation can be fundamentally as simple as giving your customers what they need, when they need it.

I like to use the example of Nest, the smart home thermostat. Nothing about the product is fundamentally disruptive. It's just a really well-designed piece of old-school tech with fresh "machine-learning" jargon sprinkled on top. But consumers love the product because it combines existing technology, intuitive user experience, and addresses our simple daily needs in a connected world. In this article, I write about the processes a company can follow to build better products when planning, building, and then releasing products to market.

Before: Preparing to build a product


Paralysis through analysis is a common ghost that haunts the innovation halls of many enterprises. How deep should we dive? How long should we collect requirements for? Does our sponsor have the deciding voice since they’re funding the initiative? Teams tend to overanalyze and over-document requirements. Very early on in any product strategy, we believe in-depth requirements are useless, because the team is operating without customer feedback or validation. Yet, there may be consensus in the business around which idea(s) should be tested. If not, we suggest that you check out the Stage-Gate process for collecting and prioritizing ideas.

To get started in a Product Thinking environment, you need four things:

  1. Lean Requirements. A great starting point to needs identification is to assemble a stakeholder group from a variety of organizational functions, ranging from the back office to senior executives, of up to 15 people. This group participates in a lean requirements workshop (generally half a day), which results in a common understanding of the problem, potential needs, and areas that need further investigation. You can find more detail in our failure through documentation article.
  2. System roles. The team building the product should interview core stakeholders and build user personas for each type of individual who will interface with your product.
  3. User Research workshops are scheduled to further inquire into an area where a strong bias exists or there is a fundamental lack of knowledge. For example, we ran user research workshops for a manufacturer that wanted to better understand the needs of their field service technicians. They had a general understanding of some challenges but felt that an in-depth, direct conversation would be beneficial to the product development. We scheduled two days in our office and brought in 30 of its largest partners. We learned that the technicians primarily worked on sunny rooftops and as a result, their Apple iPads tended to overheat and have massive glare problems. This insight affected our implementation strategy and non-functional requirements.
  4. A Product Roadmap captures high-level requirements; a release roadmap, as well as associated investment for the Minimum Viable Product (MVP); and, several subsequent versions. We know that the roadmap will have significant changes as soon as the MVP is tested, but this still helps capture the long-term vision and sets realistic investment expectations.

All of the above activities can be accomplished in a matter of days or a couple of weeks. That’s the general idea—lean requirements, a shared understanding of the problem, and the ability to move and pivot quickly as the landscape changes. This allows your innovation team to produce results without typical delays. Additionally, your spend-to-date is minimal since your working team is small and your stakeholders are involved for short workshops only.

During: Building a Product

We start with a clear understanding of business needs from our stakeholders, as well as considerations from field users. We also have collective buy-in and understanding of the problem we’re solving, and we’ve spent very little money. Then, onwards to building a prototype!

Lean Requirements Workshop

I would like to stress that even in the build phase we are not overcommitting. Our activities here are focused on producing a working piece of software, but we’re doing it to further validate market need and definitely not trying to get everything perfect or market-ready. Consider building an MVP or a Minimum Marketable Product (MMP). Most business stakeholders want an MMP. However, you should only build MVPs to control risk. We want to exit quickly if we see that the product is not living up to expectations that were generated in the pre-production phase. As you're building your product, consider using the following tools and processes: 

  • Rapid Prototyping allows you to put a piece of working software in front of users. What we’ve seen historically is that users will present their needs a certain way, but their behavior will change as soon as they have the product in front of them. A prototype is meant to hone in on the user needs, as well as further validate the return on investment. You can read about our rapid prototyping approach, but generally, you can start with lean prototypes built with InVision, lightweight front-end applications that have interactive UI with lightweight back-end code, or in-depth prototypes that validate user needs and contains engineering spikes to validate models and investigate integration points. These can be created in two weeks, a month, or a couple of months, respectively.
  • User testing (formative research) is facilitated in a lab with specialized equipment such as eye tracking and screen recording on desktops and mobile devices. The research exercise itself can be structured in a way where multiple products are reviewed in the same session without revealing the identity of the new product. We ran a workshop with three of the largest U.S. industrial supply companies and were able to capture a cohesive story from real customers that supported the investment into a new eCommerce platform.
  • Agile delivery is used to iterate over the prototype based on the product roadmap. Once the delivery velocity is known, the team can easily predict the amount of investment necessary to ship desired features. Stakeholders perform acceptance of deliverables in two-week increments, avoiding the feared User Acceptance Testing debacle that usually delays product launches. Subsets of functionality are further tested on the road to the MVP that is prepared for release.

Because product investment is incremental and results are visible in two-week sprints, the business can easily pivot the requirements, project total costs, or terminate the product if testing returns poor results.

After: Responding to market feedback

It’s possible that the market reacts unfavorably to the MVP. But take for example that you’ve maybe only spent half a million dollars out of a $10 million innovation budget. These are actual numbers from a New York global wealth management company's innovation announcement. A lot of money, true. However, this is hardly a setback considering the total budget. A very different story would have been published were the process linear and using waterfall.

Let’s take a look at tools and processes you can use to influence future releases of your product and your investment strategy:

  • User testing to perform summative research is very beneficial once the product is released to market. If you’re scratching the surface of a real problem the customer is having, they will be very vocal with their feedback and their product needs. We’ve seen product roadmaps that explode as soon as the application starts to be actively used. User feedback is biased, so you should also...
  • Implement monitoring and analytics. From Google Analytics, to Adobe Analytics, to Mixpanel, Flurry, and New Relic. These flexible platforms allow you to configure your data gathering rules and provide hard, behavioral data that you can use when shaping your product backlog. Your stakeholders or sponsors may be very vocal about features they see as absolutely mandatory, yet analytics may tell a different story and help you maximize value delivered. Product teams have a tendency to “Gold plate” products once in the final sprints – working on over-engineering auxiliary features that may be used less than five percent of the time.

The case for Product Thinking

With Product Thinking, a bit less fear of failure, and adoption of new processes, enterprises can be incredibly successful by making the customer happier, the software easier to use, and the employee more productive. Take a look at the automotive industry and what is happening with autonomous vehicles. That’s a very, very long road traveled with first AI tests happening in Stanford around 1960’s. And while autonomous vehicles will completely transform the transportation industry eventually, automakers have been innovating and incrementally improving our driving experience for more than 100 years. Much like the three phases above (Before During and After), individually these advances don’t seem “disruptive." Yet, taken as part of a whole, and in contrast with cars even a decade ago, you realize how much progress has actually been made.

The technology available to today's businesses, its employees, and its customers have been evolving at a staggering speed. Most enterprises are not even scratching the surface of what is possible with mobility, IoT, predictive analytics, wearables, and other technology toolkits. The people on the front lines of your company know what the company needs, but a little change is needed. Is your company ready to innovate?

Looking for more on this topic?