A business model is a starting point for identifying a product idea and drawing up a plan. The desired outcome of this plan is to identify the unique value proposition that our business intends to deliver to the users/customers. In order to arrive at this, we need to define who our users are, what problems we're trying to solve, what channels we can leverage, who our competition is, how we plan to make our revenues, and what costs we might incur.
For start-ups, or businesses in the early stages of development, Lean Canvas, or any other framework that can help to visualize the market, business ecosystem, unique value proposition, and target segments, is a great place to start. Even for a product manager joining a team midway through product development, understanding the vision, market and target groups, and so on is key. After all, context is king. If the business model hasn't yet been laid out, then I recommend that you do that first.
Lean Canvas is a fantastic tool for capturing the business model around a product. Product Vision Board is also another tool to help us to visualize the product vision. Defining the business model around the product is a great way to define the target customers, the problems we're trying to solve for them, and the unique value proposition that we can offer. This can form the basis of how we want to run our business. Not every aspect of our business needs to be productized. Also, not every user segment may value every product feature with equal merit.
The business model can help us to visualize these target segments and capture which segments we want to go after in the current phase of business. However, Lean Canvas stops at the business model level. When investing in technology, we need to be clear about the outcomes we seek and the trade-offs we need to make. Building a product requires that we understand the larger business context, but we iterate on a product strategy that helps us to deliver a solution that meets business outcomes and provides value to customers. Software technology is extremely flexible. We can build quick and dirty solutions, or we can build robust, long-lasting solutions. However, every product must be based on business and customer motivations, and not on technology preferences.
The following is the Lean Canvas model proposed by Ash Maurya:
The overall business plan may also vary depending on the stage of the business. Business context and constraints have a bearing on what is achievable. For instance, at early stages, a business may be interested in creating value for early adopters. Some businesses may not attach importance to revenue generation until there is sufficient traction. As a business scales, other goals may become important. Value creation becomes more comprehensive.
This relationship between business outcomes, a customer value proposition, and an execution plan can be represented as shown in the following diagram:
Throughout this book, we will use a sample business case to illustrate concepts. We will use an imaginary business called ArtGalore, which is an art gallery specializing in curating premium works of art. The company now wants to venture into creating a digital art viewing and purchasing experience for premium art buyers.
Let's look at the Lean Canvas model created for ArtGalore. The following is a sample representation:
In the preceding Lean Canvas model, the unique value proposition describes the concept of a digital art buying experience, the success metrics define the business goals, and the solution describes how the business intends to deliver the value proposition to its clientele. At the stage of problem/solution fit, the actual execution plan of how this digital experience will be created is not yet finalized. Even the value proposition, target segment and solution are yet to be validated. The Lean Canvas model represents the big hypothesis that the business is making about its growth in the next two years. The Lean Canvas model, in a way, also represents a slightly longer-term view for the business. Along the way, as the business discovers more about the customer's perception of value and actual growth indicators, the canvas could change and ArtGalore could pivot to a different business model if the hypotheses are proven wrong.
From a product development perspective, we need to identify the three aspects of product success discussed earlier in this chapter.
What does the business hope to achieve by investing in a digital art gallery? The success metrics shown in the Lean Canvas model are a broad indicator of long-term goals. Building a brand and doubling revenue are long-term goals. In order to work toward those goals, the business needs to make some product investments in the short term.
The unique value proposition, and the solution concept, coupled with the customer segments, as described in the Lean Canvas model addresses this. It is natural for us to jump into ideas about product features, but before we even arrive at features, we need to think about user personas in our customer segment, and define how the solution will help to deliver the unique value proposition to them. Eventually, the features get refined into product functionality.
There can be many ways to deliver the value proposition to the customer and to meet business outcomes. The execution plan for delivering the value proposition and business outcomes can depend on the ease of execution, cost of execution and, potential to create a positive impact on business outcomes. While the preferred solution for ArtGalore is a digital art gallery, not all aspects may need to be built in upfront. The execution plan must factor in the strengths of all the business functions that exist in ArtGalore. The focus must not be just about how technology can solve all customer problems/meet business outcomes. The focus must be about how to work seamlessly with business functions and ensure that the end-to-end product experience is satisfying.
Business constraints includes factors such as the time available to go to market and the potential to raise investments. Governing policies, regulations and compliances (if any), technology potential, capabilities, skills available, and so on can also influence business goals and the product experience. These factors will determine the key goals to focus on, the product features to offer, and the best way to implement them. In addition to constraints, the intrinsic business intent is important. What are our uncompromising principles? What do we value more? What values drive our decisions? What is our appetite for risk? These factors will decide how we deliver value.
A product can impact the business or the organization that is creating the product. It can also impact the customers who will adopt the product. 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.
Based on the unique value proposition and the business context and business outcomes prioritized for a specific time-bound milestone, the following is a sample illustration of the inputs for product development for ArtGalore:
This is quite a simplified representation of the product development inputs at a given point in time. The diagram illustrates how business constraints may influence what the Impact Driven Product may deliver to the user.
The preceding illustration indicates that the most important outcome for ArtGalore is to become the first choice for art among its target segment. The most important aspect of the value proposition is offering tastefully curated art collections for existing buyers who don't have this information today. The most effective plan to execute this solution is to offer digital newsletters, provide an online sign-up for upcoming art shows, follow up on the sign-up with invites, and announce the website. This has been identified based on the business constraints of being ready for the upcoming art show, not compromising on the existing buyer experience, and so on. The other solutions, value propositions, and execution plans are also great, but given the business constraints, the Impact Driven Product is where we want to steer all our resources to.
Minimum Viable Product (mvp) is a concept that is quite prevalent in the software development scene. There are different interpretations of the concept of an mvp and Chapter 6, Managing the Scope of an Impact Driven Product dives into the interpretations of minimum viability.
At a basic level, an MVP intends to test the riskiest proposition of a business idea or a technology, without running out of resources. This is very helpful when testing an unproven technology or when building under tight business constraints. However, an mvp falls short in terms of delivering an end-to-end product experience to the consumers. The problem with how we define an mvp is that we tend to view technology viability as a value driver operating in isolation. An mvp is great in the problem/solution fit stage, but in the product/market fit stage, there are many other aspects to consider. When launching a new product, there are umpteen activities that need to be orchestrated to ensure success. Marketing, sales, support, and other operations need to come together to ensure a product's success. Testing viability of a product in isolation isn't going to ensure success for the business.
In my start-up, we had built up a platform for businesses to design and build mobile apps for client engagement. We had started out in the events and conferences domain, where app creation lead times were pretty low, audience engagement was critical, and last-minute changes to a schedule were quite common. Our platform was geared toward addressing those needs, but we soon started seeing interest from other business verticals who saw the potential that our platform had in driving customer engagement. One such business asked us to enhance our platform with the bespoke functionality.
We were in early stages in our start-up and naturally we got quite excited about the opportunity. The possibility of opening up our platform to another domain was quite lucrative. While we didn't see much value in creating a custom solution for a single client, we realized that we could enhance our platform to cater to the entire business vertical. This would also give us a great opportunity to launch our product into the B2C space. So, we carved out an mvp for this, and our engineers got busy with re-architecting the platform to make it flexible across business verticals. After spending more than a month on this, we were more or less ready with the revamped software.
Our revamped product was technologically viable. Yet, was the revamped software impact-driven? No. Why? We hadn't looked at the end-to-end value of the product. Our business model was different. Our target audience was new. A B2C market needed a very different approach. We hadn't planned for marketing, content creation, and promotions. We realized that we had neither the right skills nor the investment to drive this product to success. We hadn't really defined to ourselves what the new product would deliver. After all, we had just one customer who was interested. We hadn't looked at an end-to-end product experience.
Our rookie mistake cost us a month. We ended up shelving the product and didn't even close our sale with the one customer who showed interest. From the software perspective, we had it all covered, but we had not given any thought to the whole product experience or to the outcomes it could generate for our business. We are much better off today having learned and recovered from that mistake quickly, instead of having gone down that path, purely riding on the viability of our platform. We had looked at one customer's request and created a hypothesis about the problems our new platform could solve and the needs it could satisfy for that customer segment. We were confident that the product would address their needs and it could have. However, we hadn't given any thought about what it meant for our business, the stage we were in, our internal capabilities, and our weaknesses.
I know many developers who take great pride in how their software is built. The prevalent thinking is that if you build your software right, it will take care of itself. I've seen very smart engineers express deep disregard for supporting functions. They look down upon marketing, promotions, and sales saying, "People will adopt our product because my software is great." However, success isn't in and of the technology process itself. This is a core difference between task-oriented thinking and goal-oriented thinking.
Businesses make the same rookie mistake when going after early adopters. We want to get our business model validated quickly and cost-effectively. So, we build an mvp with a lot of loose ends on experience, revenue generation, and operations. Then we identify a safe pilot group from our family, friends, and well-wishers, or we offer our product for free to anyone who agrees to try it. Early adopters need to be potential (paying) customers who will risk adopting a product with partial experience, because it solves their most pressing needs. They will risk an incomplete product as long as their needs are met.
However, if we don't choose our early adopters right, we may end up validating the wrong product, which then tanks in the product/market fit stage. For instance, when we offer our product for free, how do we know if the customers are adopting our product because they see real value in it or because it's free? We feel happy with the validation we get for our software, but as we move out of that pilot group, we realize that our product doesn't have many takers. This is because we may have chosen our pilot group safely and they told us what we wanted to hear. The real test for a product is in testing out the riskiest propositions. The riskiest propositions are not just about how our product can create customer value, or about the technology viability in delivering that value, but also about the business capabilities.
If we're building a business, then we need to have a plan for how to make it grow, create impact, and be sustainable. Good software is never a replacement for a sound business model and vice versa. A product entering the product/market fit stage should have validated the viability of the riskiest business/technology propositions. Product/market fit should focus on offering an end-to-end product experience that offers the most value to the consumer and meets the business outcomes. The learnings that we have had right from product ideation and beyond have to continuously feed into the product experience. We need to think about a holistic product experience, rather than the feature set or technology.
If we don't realize that a product experience is a result of many technical and operational parts coming together, to meet a larger goal, then we're just missing the point. After all, we're not just laying the bricks; we're building a cathedral, a hospital, or a school.
An Impact Driven Product is the one that combines the technical and operational aspects of a product to create a holistic product experience. It comprises the entire product experience, across all touchpoints, for the customer. The Impact Driven Product ensures that we carve out a product, knowing full well what business outcomes to target. We factor in the support and co-ordination we need from business functions. We identify the smartest way to deliver value to customers under given business constraints. Knowing Key Business Outcomes is also a critical input to product development, and this should not be a one-time activity.