Wrapping up the product discovery phase requires pulling different experts from Infinum. We’re talking POs, solution architects, designers, and analytics experts – all of them are needed to create a feasible plan for bringing this product to market.

There are a few key questions we need answered to be able to move into the delivery phase of the project. We’re now in the hard planning mode making both strategic and tactical decisions about the product.

• What’s the minimum viable product? What’s the minimum marketable product? (And is there a difference between these two?) → MVP should really have the least amount of features, while MMP should be only a tiny bit bigger than the MVP. A huge difference between these two indicates there might be a mismatch between user needs and the product
• What are organizational and tech risks, and how do we plan to overcome them? Who needs to be involved, when, and what are their deliverables? → The client and we need to have clarity on the negative pressures on the project delivery and have a plan on how to mitigate those risks. No risks detected signals that we did something wrong during the Discovery phase.
• How do we plan to bring this product to the market? Who should be involved on both Infinum's and the client's side? → A robust and feasible plan for educating the user base, converting and retaining them that’s dipped in well-researched user needs.
• What are business and user metrics of success, and how will we track them? → A focus metric that’s clearly connected to the product’s value proposition and a logical and actionable list of supporting metrics that will help guide product development post-launch.

Value-effort chart

The value-effort matrix chart is used as a way to help clients prioritize features and find their MVP. On a 4-quadrant chart, value is plotted on the x-axis and effort on the Y, or vice versa. The objective of the exercise is to place the previously created and refined user stories and plot them appropriately on the quadrant where they can be measured and assessed.

Start with value, as this is likely the more important element to consider. Once plotted, utilize a tech representative such as a solutions architect to estimate the effort of the user story best.

Once your top user stories are mapped, write down the stories in order from highest value and lowest effort to lowest value and highest effort. Implementing high-value, low-effort features is a strategic way to quickly add value to your product while knocking out low-hanging fruits.

For a summary of this exercise, see below:

• Use the FigJam template for the value-effort matrix exercise. Ask the PO/PM to write down any user stories if this has not already been done.
• Start by locating the collection of user stories in FigJam or ask the client to find the user story that’s the most valuable and then the one that’s the least. This gives you the relative scale.
• Have the workshop participants collectively rank the user stories according to value. As a strategist, you should lead this discussion and ensure that all member’s opinions are voiced. Move story by story until you place them all within the chart. Once agreed upon, place the user story at the correct location.
• Ask our SA to line up user stories or features on the effort scale.
• Discuss if the story mappings fit the product vision.
• Use the outputs of this exercise to create a user story map and phase roadmap with the PO/PM, based on the value-effort chart. Discuss this internally with the team.

User stories mapping

The roadmap vaguely resembles a table with labeled product phases such as alpha, beta, MVP, and MMP as columns and features or user stories plotted in the rows.

The idea is to plot user stories in order on a roadmap from left to right, top to bottom, in rows and columns. Rows have bigger features such as login, chat, and similar. Columns show how sophisticated each feature will be in each release and stage.

A rule of thumb is that as you progress right in the columns, each new column will represent a leap in product capability. Keep in mind that some features won’t be built or upgraded in some releases. Consider using Miro or Figma to create this roadmap.

Once the roadmap is complete, it is time to present it to the client as the v1 and the basis for discussions. If needed, show this to the stakeholders in the client company and make sure to get their sign-off.

Analytics framework

Analytics provide the basis for stakeholders to make decisions in the best interest of the company, and the users, according to the data. In order for analytics to be produced on a product, a data pipeline must first be established within your product and you must have an audience to use or already using the product.

Analytics colleagues can do their best work when they're provided user story maps and when they have some designs to reference. User journeys provide an opportunity to capture and collect various data within your product.

Once you have journeys created, sync with the analytics team and ask them to create a WIP analytics framework based on those and the various user personas within the product.

Plan this framework as one of the exercises in the last days of your workshop. Involve Analytics colleagues once you have the user stories map ready and let them prepare for the workshop. They’ll do most of the talking, while you’ll be there to support them in facilitating the discussion.

Some frameworks they might use are FMF or AARRR. It’s up to them to decide depending on a specific project. They’ll prepare a test set of metrics based on those frameworks, walk the client through those, and start a discussion.

Since implementing analytics costs time and money, clients need to see value early on. Allowing them to have a say in building the metrics framework does just that.

Stakeholder mapping

You need to know who’ll be talking to and what are the internal politics within the client's company. Understanding each person's role, seniority in decision-making, and level of involvement in the workshop will help you create this stakeholder map for you and your team to refer to during critical decision-making periods.

It is important to enable all participants to share their input but do not forget who gets the final say in some of these decisions.

When creating the map, you can split them on two axes: power and interest. Power implies the weight of that person in decision making whereas domain knowledge represents the expertise that person has to the particular challenge being solved.

Interest shows how important this project or product is to that person. For example, some stakeholders may dual as the product owner of a project, and may have a particular interest in the success of that project. Success could lead to a budget increase in that department, a salary raise, or a promotion, for example.

In reality, this means that this person might be able to dedicate a significant amount to time to working with you. Try your best to get them as involved as possible as these types of stakeholders should want the project to succeed as much as you do. Make these stakeholders allies and figure out how to best utilize them as a resource.

Power tells you if that person has decision-making power over the budget and the product. If someone can cut off the funding, then they’re someone you need to manage carefully.

Template for this exercise → FigJam

Flowchart and information architecture

This one is a very designer-heavy exercise. You're trying to understand the informational underpinning of the app.

These most often include:

• Sitemap: A tree-like visualization of different pages on a site (or within an app)
• System attributes: A list of all the entities withing the app, their characteristics and the way those entities are connected
• Flowchart: Visualization of all (or at least most) of the screens in the app and their mutual connections

Pro tips

To be effective at creating your information architecture, be sure to follow these recommendations:

• Be sure to structure the information in a logical and meaningful way, often through hierarchies, categories, or other systems that make content easy to understand and navigate.
• Be sure to clearly assign labels and names that are consistent to ensure that users can easily comprehend and identify content.
• Be sure to create intuitive navigation so Navigation: Creating intuitive pathways for users to move through information, enabling them to find what they need efficiently. This involves designing menus, links, and other navigation systems.
• Content Strategy: Develop a plan for creating, managing, and organizing content to ensure it meets user needs and business goals.

You can read more on the information architecture in the Design Handbook.

GTM canvas

A strong go-to-market strategy sets the stage to increase the potential to adopt your value proposition and convert a user or customer. A GTM canvas is a blueprint for aligning internal stakeholders around what you want to accomplish and what you need to consider when bringing a new product, service, or venture to market. GTM usually has two main parts: business landscape and go-to-market approach.

Business landscape

• Market Need, or the problem we are trying to solve
• Value Proposition, or the value of the product or service we deliver, from its benefits to how unique our differentiation is in the market
• Competitive Landscape, or the product or company’s position relative to its competitors
• Pricing, or the product's price point relative to the market and competitive landscape
• Customer Segments, or the users or customers you serve (ideal & actual)
• Communication Channels ie. how one expects to communicate with the customer and deliver the value proposition?
• Customer Pains, ie. what user pains does our product solve?
• Customer Gains, ie. what a user gains by using our product?

Go-to-market approach

• Release strategy, or what will be the phases of releases, and what’s the rationale of splitting the product into those phases?
• Goals, or what are we trying to achieve through a digital product, think: fewer calls to the Contact center, more subscriptions, bigger webshop basket, and similar
• KPIs, or goals turned into measurable metrics
• Distribution channels, such as digital and offline ones
• Key messages, or what do we want customers to remember about us
• Creative direction, or what will the supporting visual or visuals, how do we make this product stand out visually on the market

Template of GTM canvas → FigJam

Tech limitations

Understanding the limitations of the technology used in creating your product is a critical step in this process. Many people overestimate the capability of technology while simplifying the amount of sophistication and complexity it requires to create basic applications that run smoothly.

Exploring and defining technology limitations begins with an understanding of what it is you are trying to build, the services and tools involved in making that a reality, and what is possible given the time, financial resources, and constraints.

This part of the Solution workshop is led by an SA.