Time-bound priorities for Key Business Outcomes

To create the best product experience, we must align product-building and business operations. To do this, we need to find the most important (one to three) business outcomes for a definite timeline. The reason I'm saying one to three outcomes is because in early stages of product development, it is best to steer our resources toward fewer outcomes. Going after too many goals can be counter-productive and can result in a loss of focus.

Quoting Eric Ries, author of The Lean Startup, here:

"There is no reason why a product cannot have both high margins and high retention. However, in my experience, successful startups focus on just one engine of growth, specializing in everything that is required to make it work."

Even when we focus only on growth, sustainability, or influence as our high-level goals, we may still need to refine to one to three outcomes within these high-level goals, to ensure that we direct our efforts constructively. Based on the Key Business Outcomes, we can determine which product functionality to pursue and which functionalities are likely to be the most impactful.

Setting a time limit helps us to define realistic product backlogs. We can then track success metrics and evaluate whether or not the product is working/successful. This is typically the time needed to excute a plan and start seeing results. We need to be able to assess whether the product is meeting desired goals or not. An indefinite timeline may lead to overengineering. Why? Let me recount an experience from a software engineer who left his day job to start up a business in online music streaming. He had started with a great idea and immense passion. When I met him, he told me that he had been working on his product for a year.

When I asked him how many users had signed up, he said, "None!" I was quite curious to know why this was the case. When I probed further, he explained that he wanted his product to be perfect. He kept adding tweaks and subtleties, trying to make his product good enough to be showcased to the world. He hadn't set himself a time-bound goal, nor a milestone so that he could meet specific goals. He kept pursuing perfection, and this pursuit was limited to his choice of features (functionalities) in the product. His pursuit of perfection in how the product was being built was not supported by an equal zeal to meet any outcomes. He hadn't thought of how many users he wanted to acquire, whether he wanted to make revenues from his product or not, or what users might want in the product. He was running out of money in about three months and was desperate to find takers for his product. He hadn't laid the groundwork for anything other than the functional aspects of the product. He had been running on an indefinite timeline and overengineering a product that had neither users nor a business model.

Ash Maurya, in his book Running Lean, describes the three stages of a start-up:

• Problem /solution fit
• Product /market fit
• Scale

The development of a product follows the same stages. The problem /solution phase must be less about product development, and more about validating the unique value proposition.

Once we have validated the unique value proposition, we have a clear idea of what the product is, who our customers are, what alternatives we trying to replace, and so on. This is the phase where we're trying to see if our product meets the needs of our customers. Product /market fit is the stage where we figure out if our product can meet the market's needs. Does the market see value in our product? If yes, then how do customers value our product? How does that translate into a business outcome for us? The third stage of scale happens after we have established the product /market fit and have found a business model that is repeatable, and the quest is to accelerate growth.

The Impact Driven Product, as we saw in Chapter 1, Identify Key Business Outcomes, is a combination of the why, what, and how under the influence of internal and external factors. An Impact Driven Product, therefore, is one that finds the best way to deliver value to customers and meet business outcomes under internal and external constraints.

During the problem/solution fit and the product/market fit stages, we define the product, measure its success, and iterate on our learnings. It is important that we keep the build-measure-learn loop short. It must be short enough to ensure that we don't overengineer our product and long enough to be able to deliver something of value.

Typically, a few weeks to a one or two-month period can work well when we're in these early stages of product development. It helps us to keep our validation cycle shorter and keep our focus on identifying our Impact Driven Product. As our product matures (gains traction), we start seeing evidence of success in business outcomes. We then decrease the frequency of this validation cycle or increase the duration of the validation cycle. We could extend the frequency of investing in Key Business Outcomes to four to six months, depending on the nature and maturity of the product.

There is of course the question of what if we cannot implement an idea in three months? What if we don't have the right skills, or the resources, to meet the business outcomes? We still need to understand realistic implementation and validation timelines. This is what we will establish in later stages in the development cycle described in the next two chapters.

Trade-offs in time-bound planning

When implementing software, there will be trade-offs that we need to make. The product trade-offs might be about speed, quality, performance, reliability, or scalability. Typically, we categorize them under nonfunctional requirements. Some get classified as technical tasks and never make it onto the radar of nontechnical folks. This is where most of the disconnect between the technical and nontechnical teams arises.

When we're in the early stages of product development, we tend to have a narrow product focus. We target a limited set of early adopters. We may also look at a limited feature set. One of the main reasons we want to do this is to iterate through the build-measure-learn loop swiftly. We want to validate our product assumptions at the earliest opportunity, so sometimes the quick-and-dirty code may just work. The problem here is that the product could have defects. It might not work well for all use cases, it might not scale or be very responsive, and so on. Yet these trade-offs are being made at the product engineering level. Without understanding what measurable outcomes that we seek from the product at this stage, we cannot make educated trade-off decisions.

For instance, what is our idea of early adopters? How many users are we targeting? If a product works well for the early adopters, how soon do we want to scale to the next level? What if we started with 50 customers, and now we have 200 sign-ups? What trade-off is the business willing to make? Is it OK if we lose customers because of limiting performance or defects? Should product teams decide this in isolation? Don't other business functions have a stake/say in this?

When making trade-off decisions in isolation, technical teams build defensive code. They are unclear about success metrics. They assume that the business will come back with more sales, so they build less features, but more robust software. Nontechnical folks, when making trade-off decisions may do so with a poor frame of reference about technology. Evaluating the benefits of the effort involved in building quick-and-dirty software versus robust scalable software, can be hard. The end result of this disconnect is the loss of experience for customers and the loss of value to a business.

In some cases, there may be immediate benefits. Defining the timelines for realizing product benefits in terms of actionable metrics is required to define what to build now and what not to build now.