In early 2000, I worked as a business analyst. We were following the waterfall methodology, and I used to maintain huge 500-page requirements documents. Waterfall methodology assumes that software development happens in stages. The first phase is to understand business requirements. It is followed by designing and architecting the solution. Solution development starts only after the architecture is signed off testing begins only after development is complete, and so on.

Interactions with business stakeholders happened primarily at the requirements gathering phase. When building a large solution, that phase could run into months. There wasn't much interaction with businesses, or customers, after this phase. In my case, most of my interactions used to be confined to the analysis team. We used to be isolated from developers and testers. I mean, we actually sat on different floors, and in one instance, testers were in a different building altogether!

For the entire solution to be delivered, it could take many months, or even years. By then, a lot could have changed on the business scene. My first experience of understanding the impact of this came by chance. I was asked to fill in for my manager on a year-end prioritization call. I had to read out a one-line status update about a project we had been working on for six months at that point. I had no inkling about what the call was about. As a rather naïve junior analyst, I had no idea that all the regional business heads were going to be on the call. Toward the end of the two-hour long call, the facilitator read out a list of projects that were ongoing and in the pipeline for the next year. Every regional head made a go/no go decision, indicating whether they were willing to sponsor that project or not.

To my shock, an application that one of the teams had been building for two years got rejected. Poof! Just like that, two years of software development turned to ash. I was intrigued. How could this be? Why would they waste so much money building something and then scrap it on a whim? Was this only a problem with waterfall? How could we have anticipated business priorities?

I have witnessed many Agile projects shutting down not because we weren't building things right, but because the business context had changed. In some cases, the business ran out of money. Product teams were not closely aligned with business and while the business context had been shifting for a while, the previously identified backlog was still being built. In other cases, the product wasn't rolled out to users until much later, and adoption went downhill. Agility helps in responding to changing business context, but what if we could predict the trends of where the business is heading? The problem also occurs when business functions don't collaborate and work toward the same business outcomes. Even when the situation isn't calling for something as drastic as a shutdown, product teams are often taken by surprise about how a feature is perceived by a business. Business priorities need to align with every aspect of product building.

I know many a software engineer who is confounded by the idea of a quick-and-dirty working code, even when the code meets customer needs and business outcomes. I have seen business stakeholders fuss over the exact hue and shade of the brand colors in the user interface, and not really care so much about how performant the system is. Sometimes, this is due to an incorrect frame of reference. Some stakeholders don't really understand the effort that goes into optimizing a page load for an image-heavy website that is used by a million users. So, they may just brush it off and say, "Of course, that's to be expected. Why would it be otherwise?" This is because we make some assumptions about product outcomes. We treat a business outcome as a one-time requirement that is frozen for the lifetime of a product. We then iterate only on a product plan to deliver product features. We make assumptions about which customer value proposition is important. The business (as a whole) should determine trade-off decisions, the value proposition, and what customer feedback to act upon. Understanding business outcomes should also be iterative.

What value proposition do we need to deliver in our product? What business outcomes are we trying to meet? Isn't it wasteful for developers to build a highly performant system, when product differentiation is what we're going after? Isn't it just as wasteful for marketing teams to strategize about reach and engagement, when what we're really looking for are a few early adopters? These questions require collaboration and collective decision-making.

As shown in the preceding illustration, each of us holds a certain view of the business potential. Each of us is right in our own way. Brand messaging, sales follow-up, integrations to ease operational activities, and planning for scale are all good, but is it the right time now to address them? What determines this?

Where we direct our efforts depends on the present context of the business. This should not be a choice that business functions make in isolation. Business functions (product, marketing, sales operations, and so on) should collaboratively make this decision. Why we choose one way to execute over another, or what trade-offs we make, depends on the intrinsic organizational makeup. The combination of context and this choice determines business intent.

At every stage in a product's development (and especially at the start) we need to identify what drives the business intent. How do we plan on delivering the unique value proposition of our product to the customers/market? What would tell us that we're doing the right thing for the business? What aspect of our value delivery is most important for us? What trade-offs are we making?

Growth, sustainability, and impact are pretty much the goals for every business (nonprofits and socio-political organizations may align better with impact than profitability). Yet if the business is not making money sustainably, or influencing sustainable change, can it exist? Should it exist? With this business goal, we can come up with a list of outcomes that are pertinent to the present business context. These outcomes can help us to align our product value propositions. They are the Key Business Outcomes we want to track. Each business outcome would have its own success metrics, which we can measure.

Some of these Key Business Outcomes are listed as follows. This list is indicative and generic. We may be able to identify other outcomes based on the context of our business. Typically, aim for not more than one to three outcomes:

As you may note, some of these outcomes are tangible and easily measurable, for instance, acquisitions. Others are quite abstract, such as customer satisfaction or marketing reach. In the next few chapters, we will try to define the criteria for measuring every business outcome.

Every business is unique and goes through different stages of maturity. Therefore, some business outcomes are likely to be more important than others, depending on which stage of business we are at, and what type of organization we are. Also, it's nearly impossible to go after everything listed earlier. We may spread ourselves too thinly trying to achieve success in every aspect. We will need to make trade-offs, and those trade-offs need to translate into the product.

The unique value proposition from our business model and the Key Business Outcomes form the basis for defining the Impact Driven Product. The following representation indicates the various steps in the Impact Driven Product development cycle:

We will review each step in the Impact Driven Product cycle in the following chapters.