Product Strategy

Strategy Sprints

Product Strategy the first step in defining an incredible product.

Product design sprints let us dig into critical business questions through design, prototyping, and testing ideas with customers. Inspired by the work of the team at Google Ventures and tailored to the needs of our clients, this phase of the process gives us a high-payoff, low waste way of digging into an idea and better understanding the market.

Design sprints can be 1–2 weeks and focus on digging deeper into an app idea and finding out more about what the core value will provide to customers. The key here is to cut down on time debating over the details of any one implementation, and instead put it as quickly as possible in front of who matters most — the user.

During Sprint 1 the team will test the project’s biggest assumption or biggest risk. Based on what is discovered in Sprint 1, the team will take one of two courses in the second sprint. If the data shows the product has a solid foundation and has a foothold with users, we will spend the second sprint refining the previous sprint’s prototype and testing smaller assumptions.

If the sprint illuminates a new piece to the puzzle we hadn’t thought about before or a user need that is more pressing than the one we initially set out to research, we will pivot and test a new prototype in the second cycle.

This is the stage of app development that offers the highest return on investment, more than any other stage in the process. Two to three weeks of product design sprints will allow validation of whether the product in question will be a hit with users, and here can determine that in 80 hours of strategy as opposed to 800 hours of development. This “hack” avoids building two to three full-fledged apps (something that would likely take a good portion of a year) and shipping them to your entire user base and instead ships two to three prototypes to a small, representative set of users in less than a month.

These are some of the most common and valuable exercises of Product Strategy:

• Understanding business goals, user outcomes, and personas
• Selecting metrics and success criteria
• Market research
• Competitor analysis
• Challenging assumptions
• User research & testing
• Creating prototypes
• Performing user interviews
• Identifying pain points and opportunities
• Finding product-market fit
• Determining the most valuable features to build first
• Solidifying the vision and project plan

Build — Measure — Learn

Product Strategy Sprints, like agile methodology, are an iterative process that we call Build — Measure — Learn.

Learn

In the initial state of product strategy the team will focus on learning as much as possible from our customers and their teams about the target market. At this stage it’s important to focus on the problem the technology is solving.

We will discuss your business objectives and key performance indicators, dig into relevant market trends, and be curious to hear about the marketing and launch plan. As we hone in on the biggest opportunities and risks, as a team we’ll begin to prioritize for our upcoming experiment with users.

The initial Learn phase will conclude when the team has decided on the most important part of the product to test and solidified a testing schedule.

Establishing a testing schedule before the details of the test have been worked out helps keep the sprint timeboxed and force creative solutions and low-waste tests with low production costs.

This discussion will help lead our team to get a better understanding of the underlying technical architecture required to build your application. The amount of back end support, integrations, and organization of information will start to come into a bit better picture in this phase.

Build

Once we understand the target market and the users, then it’s time to build!

We design an experiment so that the results will teach us what we want to learn, based on what was prioritized. This is the idea creation process based on success metrics and criteria that we first discussed.

We may build a digital prototype with Sketch and Marvel. We may draw a physical prototype on paper, or better yet, construct a physical representation of the product.

The prototypes might be focused on a few specific assumptions or risks, such as if users are willing to pay for a service, or a few specific features, which may decide if an app’s ability to broadcast to social media versus share directly via text and email is more important to users.

This method of rapid prototyping is meant to simulate the core user journey of a product at the lowest possible fidelity, cost, and time investment. The goal is to create something that is testable and will enable us learn what we need to.

Measure

We have our hypotheses and we have our experiment, now the magic happens. As we execute, we keep track of the results, the user responses. We record quotes, questions from users, and actions taken.

As we collect all of the data the team will analyze their research findings and begin to draw connections between the different types of users that were tested and the results that were found.

These insights are distilled into pain points and opportunities, which are translated into product features and requirements, and are prioritized by importance. This builds our product backlog, influences the technical architecture, and prepares us for development.

At this point, there will be two directions the product team can take. The first one is to rinse and repeat based on what was learned in the first sprint. The second direction is to move to the next phase of development.

In the case that the team learns something that fundamentally shifts the idea of what may be the right product to build (or who the right market is), performing another strategy sprint is likely a recommended choice.

The key here is that your team is open and ready to react based on what we learn in testing.

Even findings that are unexpectedly negative end up as positives in this phase since the team is so readily adaptable.

This decision will be made by both of our teams together, so that we can make sure the direction we decide on is still in line with the business vision.

The other thing to realize here that these two options aren’t mutually exclusive — in fact, we often encourage folks to move forward in both directions — starting development, and continuing strategy sprints concurrently.