The concept of a minimum viable product (MVP) helps product and engineering staff identify and develop the next most valuable product increment. For a startup, the MVP helps the team learn about product viability by iteratively exposing potential customers to small, cohesive product increments. [1] For an established product, MVPs deliver customer value through successive delivery of small product slices and drives teams to make smarter choices about their product’s future development. 

In our experience, the definition of a MVP can refer to different things including minimum marketable feature, minimum testable product, minimum valuable product, minimum feature set, or minimum buyable product. Our preference is that a MVP refers to the smallest collection of backlog items that will bring value in customer satisfaction or validate a hypothesis.

A MVP provides multiple benefits:

• Smaller chunks of change to a product can be easier for a user to comprehend and adopt.
• Products can be faster to build, resulting in more frequent releases and customer feedback.
• Small valuable slices remove waste in development and testing. This maximizes the amount of work not done while optimizing the value of work that is done. [2]
• Seeing outcomes sooner improves the development team’s learning, throughput, and satisfaction.
• The value of testing the viability of your product assumptions with product value is invaluable.

MVPs help teams deliver and validate faster. To discover their MVP, product and development teams can use Structured Conversations. These conversations mobilize brainpower, find possibilities for fast feedback, and amplify healthy, cross-discipline collaboration. Encouraging the team to contribute their intelligence and experience resonates with the benefits of agile development. [3] [4]

The Goldilocks Problem

Many teams suffer the Goldilocks problem when identifying their MVP. As you might remember from childhood storybooks, Goldilocks sought sustenance (at the right temperature) and rest (on the right-sized bed). Similarly, a product development team needs a MVP to be just the right size (not too big and not too small) with just the right anticipated value (not too little and not too much).

A MVP is sometimes represented as chunky user stories that are too broad. Shared understanding is also critical. Teams need backlog items that are defined enough to efficiently transition to planning and development. Using a telecom example, here is a typical MVP that presents a potential Goldilocks problem.

As a seller I want to manage my subscription so I can add to profitability and customer satisfaction.

This MVP is coarse-grained and masks a myriad of product requirements options that need to be explored and then narrowed down by asking:

• Are there different types of sellers and, if so, does it matter?
• How will the seller interface with the manage capability implied in the story?
• What are the actions behind the broad verb manage?
• Will just a few attributes or a larger scope of subscription data be managed?
• What business rules will need to be enforced as part of managing a subscription?
• Where is a seller physically located when they do subscription management?
• What is the composition of the technical platform that will be used to develop and operate the product and subscription management?
• Are there security, performance, and other quality attributes that need to be implemented? If so, what are those requirements?

A MVP with unexplored complexity slows down planning—let alone development—as product owners and teams clarify, specify, and focus on value. In our consulting practice, we notice agile teams and product owners spending hours in laborious meetings filling their backlog with too many items. This results in even more wasted time continually triaging large backlogs especially since most of the items might not ever get built.

What is needed is a way to balance efficiency (reducing waste and saving team time) with effectiveness (increasing mutual learning, deepening domain knowledge, and focusing on value).

That is where the Structured Conversation comes in. To do that, you must first frame the why behind the product.

Clarify Vision and Value

To set the proper context for exploring a MVP using Structured Conversations, the product vision, opportunity or problem, and value must be clearly understood. This is often stated as goals and objectives. To show how it works we will use a simplified example of a fictional telecom company, TeliCo. TeliCo’s product vision for their SubscriptionHub product offering is:

The SubscriptionHub is a software platform that enables TeliCo customers and sales partners to save time, solve subscription issues, and make better offer and buying decisions about TeliCo’s product and services. Unlike the current mix of disparate automated and manual systems used today, SubscriptionHub will provide a compelling and fun experience for our internal and external partners and customers.

Achieving this vision will solve the myriad of operational problems associated with systems in use today in a large number of TeliCo retail stores, TeliCo customer service centers, external and internal websites, and reseller retail stores. TeliCo’s goals are:

• Increase sales
• Retain resellers
• Reduce operational expenses

With clearly defined goals, the TeliCo product owner identifies quantitative objectives for each:

• Increase sales in TeliCo retail stores by 3 percent within four months of release.
• Reduce calls to the customer service call center about order status by 20 percent within three months of release.
• Improve reseller retention by increasing retail seller renewal agreements by 10 percent within nine months of release.

Creating a MVP Using Structured Conversations and the 7 Product Dimensions

To arrive at a MVP, product partners representing the customer, business and technology perspectives collaborate using a Structured Conversation. The Structured Conversation shown in figure 1 provides the framework that participants can explore, evaluate, and confirm product options using the 7 Product Dimensions. [5]

Figure 1: The Structured Conversation and the 7 Product Dimensions

A robust Structured Conversation employs visualization. Each product dimension has a distinct image and color to enhance its semantic meaning. During their conversations, participants identify and value options for each of the 7 Product Dimensions, working with a Discovery Board. [6] They may use low-fidelity tools like posters, colored sticky notes and pens. They draw models to quickly discover, visualize, and understand options. Ideally, to improve communication and understanding, the options and associated models are displayed on a wall as the team continues their discovery work.

A Structured Conversation Example

What follows is an abbreviated version of a Structured Conversation for TeliCo. For our example, we’ll focus on a “Pre-View” [7] planning horizon for a one month release. Although a typical release can include many features, we’ll show how to arrive at a single MVP. For clarity sakes, the options in the figures will use the color associated with that dimension.

The User Dimension

Start the conversation with any product dimension. For TeliCo, we’ll start exploring the options for the user dimension, which identifies people, systems and devices that directly interface with the product. For TeliCo, user options include customer servicer, retail seller, B2B reseller, individual buyer, family buyer, and business buyer.

As with other product dimensions, visual models are an efficient way to explore options. For example, personas, empathy maps, or user role maps can help explore user dimensions. Figure 2 shows the user role map that defines the relationships among the options.

Figure 2: The TeliCo user role map

After discussing the user options with the product partners, the product owner decides the most important goal is to reduce operational expenses by reducing complaints from a large number of retail sellers. She identifies the retail seller role as the highest value among the possible roles to focus on. This is marked with an asterisk to call it out to the team during their conversation. The team then explores the characteristics of a retail seller being either a novice or experienced.

The product owner shares with the team that experienced retail sellers generally log the most service tickets. Relieving their pain would repair TeliCo’s strained relationship with retailers and lighten the customer service call center’s load to resolve these tickets. By focusing on experienced retail sellers, they agree to defer targeting novices. This decision could potentially lead to more sales.

Once the first dimension is discussed, the team should be able to move quickly through the other six dimensions.

The Action Dimension

The action dimension identifies the capabilities the product offers its users. Options include search for subscriptions, establish an account, purchase a subscription, modify a subscription, purchase equipment, and modify an account. Of the list, the search for subscriptions is determined to be most valuable.

The Interface Dimension

The interface dimension identifies the how the product connects to its users. This can be visualized with mockups, prototypes or as a context diagram. Figure 3 shows a context diagram the team could use to explore interface options in the subscription interface.

Figure 3: TeliCo subscription management context diagram

The team explores several interface options as they draw the context diagram. In this case, they all agree that an improved human computer interface the most valuable.

The Data Dimension

The data dimension identifies the data and information the product retains. While investigating options in this dimension, the team sketches a subscription management conceptual data model of data entities for the customer, subscription, sales partner, subscription offering, and hardware.

The product owner points out that most service tickets are about non-campaign subscription offerings, which is an attribute of subscription offerings. With retail store observations coming from in-store queries, she concluded that non-campaign subscriptions must be the most valuable data option.

To confirm their shared understanding of the highest value data options, they explore several examples that includes the following combination:

non-campaign + unlimited voice +unlimited SMS/MMS + 20GB mobile data +iPhone7 128GB

This example helps the team refine the conceptual model into a logical data model that focuses on data scope for their MVP shown in figure 4.

Figure 4:  TeliCo subscription management logical data model

The product owner discusses various bundling options with the team and they agree the goal is to simplify the sales process. They will get more value with fast feedback from real users for a single device subscription offering. This is a better option than extending development time to add support for multiple hardware bundles. Thus, the data model in this example supports only one possible hardware device per subscription.

Focusing on the data dimension causes the team to discuss which subscription data combinations might be valid. This leads to transitioning their Structured Conversation to the next dimension.

The Control Dimension

The control dimension identifies constraints that need to be enforced, usually in the form of policies and regulations implemented as business rules. The team lists different policy options that will impact the subscriptions allowed including the following:

Valid subscriptions based on effective date

Valid subscription based on subscription duration

Valid subscription for existing customers

Valid subscription for new TeliCo customers with no competitor switchover

Valid subscription for new TeliCo customers with competitor switchover

After the team evaluates options, they realize many of these policies are combined to form even more complex policies. After some discussion, they agree that a valid subscription should be based on both an effective date and contract duration. This is the most important option that needs to be enforced with customers.

The Environment Dimension

The environment dimension represents the product’s hardware and software platforms. The team explores options and agrees that retail sellers can use a mobile device such as laptop, tablet, smartphone or the desktop near the cash register. Company research informs them that most searches originate from tablets and they agree tablets are the most valuable platform to target. Their research helps them specifically focus on the Google Chrome browser on the iPad tablet.

The Quality Attribute Dimension

Finally, the team needs to examine the quality attribute dimension, which identifies the properties that qualify the product’s development and operation. Since quality attributes can mean different things to different people, the product owner would open up discussions on the seventeen types of quality attributes identified in the book Discover to Deliver. [3] As a result, the team would prioritize and select three options as the most valuable:

• Usability: Experienced retail sellers can successfully provide search details for standard request with no help. It should take no more than three navigation actions to receive a solution.
• Performance: Results begin appearing on the interface within five seconds of submitting a search request.
• Availability: 10 a.m. to 3 p.m. GMT+5, Monday through Sunday.

Assembling Options to Arrive at the MVP

The highest value options in Figure 5 are assembled from the 7 Product Dimensions to form your MVP.

Figure 5: High-value options across the 7 Product Dimensions represent the MVP

The options defined for SubscriptionHub’s MVP can be used to create a user story shown in figure 6.

Figure 6: The MVP can be assembled from selecting high-value options from the 7 Product Dimensions

Working with the 7 Product Dimensions

As is common in Structured Conversations in combination with the 7 Product Dimensions, the conversations swivel back to dimensions previously discussed, and can take any order. This is because one dimension may be dependent on other dimensions. Indeed, they all thread together to weave a refined understanding of a MVP, story, or feature.

A benefit for the SubscriptionHub team is that they agree to focus on experienced retail sellers and non-campaign subscription searching. Recognizing how critical the user interface is to achieving their usability quality attributes, the product owner and UI designer can return to work on the interface dimension. By using the results of their earlier Structured Conversation, they can to sketch out a user interface prototype for tablets.

The manage subscriptions MVP, initially represented as a chunky story, is now minimal, valuable, feasible, and understood by the participants. With clarity and focus, their investment of time was only a short Structured Conversation. The TeliCo team can further refine the MVP into thin-sliced, ready stories to be used in a sprint. They estimate the stories based on prior history and write stories for upcoming sprints. Each story is a variation of high value, more discrete options from the data and interface dimensions, as illustrated in figure 7.

Figure 7: Using options from the data and interface dimensions to create stories

How to Get to Your Own MVP

Many product and development teams struggle without an efficient way to define their MVPs and their corresponding sliced stories. While the example we used is for a telecom, the Structured Conversation pattern has proven to be effective in a wide variety of industries including medical device, financial services, pharmaceuticals, infrastructure operations, human resources, and business intelligence.

Using the Structured Conversations to explore, evaluate and confirm future product options within and across the 7 Product Dimensions is a quick, consistent, and comprehensive approach to identity your next MVP. This approach exposes and reduces complexity by focusing on the simplest and most valuable options. Structured Conversations with the 7 Product Dimensions helps stakeholders engage, learn, and successfully deliver a valuable product.

References

1. Reis, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. New York: Crown Business, 2011.
2. The Agile Alliance.  “Principles Behind the Agile Manifesto.” 2001.
3. Gottesdiener, Ellen and Mary Gorman. Discover to Deliver: Agile Product Planning and Analysis. EBG Consulting, 2012.
4. Björkholm, Tomas. “The House of Agile – A Visualisation of the Core of Agile” Crisp (blog). January 12, 2015. 
5. Gottesdiener, Ellen and Jeff Sutherland. “Backlog Refinement Takes You from Vision to Value”. EBG Consulting (blog). September 9, 2017. 
6. Gottesdiener, Ellen. “Setting Up Your Discovery Board.” EBG Consulting, 2016. 
7. Gottesdiener, Ellen. “Planning View.” EBG Consulting, 2016. 

Special Thanks to Mikael Brodd, Michelina DiNunno, Simon Powers, and Shaun Smith, for their review and suggestions. 

About the authors

After many years as the CIO for Travelocity Nordic, Tomas Björkholm started at Crisp in Stockholm Sweden. During his nine years at Crisp he has helped companies improve their business Agility. He is a mentor, facilitator, coach, certified Scrum Trainer, and the author to “Kanban in 30 days”. His mantra is “if it’s not easy, something is wrong”.

Ellen Gottesdiener is an Agile Product Coach and President of EBG Consulting focused on achieving product agility through the convergence of agile product management, product requirements, and organizational learning. Ellen is known in the agile community as an instigator and innovator for product discovery through collaborative practices to enable healthy teamwork, strong organizations, and great products. She is coauthor with Mary Gorman of Discover to Deliver: Agile Product Planning and Analysis & two additional acclaimed books on collaboration & product requirements. Ellen is a frequently sought after speaker, author, and conference contributor. In her spare time, Ellen serves as Producer of Agile Product Open and Director of the Agile Alliance’s Agile Product Management Initiative