This is part of our How We Work series of blog posts. Learn more about how we work by reading Our Playbook.
Today, we're talking about how we use the Product Strategy Sprint process to understand context, prioritize needs, and create roadmaps. At Very, a Product Strategy Sprint typically kicks off a new project.
Once we've identified the right problem to solve, we determine realistic, viable paths to a solution — but we also go down rabbit holes. The objective is simply to generate insights, to understand the implications of radically different perspectives, to evaluate every possible approach to solving the problem. As we start to eliminate paths, we become more confident with each decision because we've explored each alternative.
Is a Product Strategy Sprint Right For You?
Maybe. Do you need to:
- Develop a phased product roadmap that provides the most value to users, as quickly as possible?
- Understand and document the full scope of requirements for launching your product?
- Mitigate project risk through technical research spikes to understand cost, complexity, and time required to build and launch the features of the application?
- Determine the correct technology stack to support the functionality, design, platform performance requirements, and constraints?
(If you're nodding, keep reading.)
We begin with information gathering so we learn everything there is to know about your business, your customers, and the problems this project will solve. We also identify unvalidated assumptions and knowledge gaps, so we can start managing uncertainty. From there, we make plans to fill the riskiest knowledge gaps and validate, or invalidate, the riskiest assumptions. We also review all existing research and conduct an analysis of competitive products.
Throughout the session, we work to define the business needs, the end users, and the solution we're bringing those users. We identify the situations in which they will use the product and its features, and we determine their motivations. Together, we decide what success looks like — for the whole project and for customers.
We'll work together during several collaborative sessions to identify and document the key components that comprise any successful business. We want to experience the platform through the eyes of a new user who has no context or previous orientation. Then, we start asking questions:
- How do we get them hooked?
- What is the point of view we want to communicate?
- What are all the ways users engage with that POV?
- What will keep them coming back?
- How and why will they share their experience with everyone they know?
We'll work together, and you will walk away with a completed Lean Canvas and any notes we've taken along the way.
Needs | Wants | Desires
The next working session is about getting to a finer level of granularity and talking about specific features. This is where the rubber meets the road and we begin to ground the concept. Together we'll work on an exhaustive list of user-facing features, necessary administrative functionality and general platform foundation. For this activity, our goal is to determine which features are critical to the business and customers and helps us start thinking how to define the Minimal Viable Product.
The session starts with everyone creating cards, in person or virtually, and placing them where they feel the cards fall in priority. The three choices are:
- "needs" (must haves, top priority)
- "wants" (nice to haves)
- "desires" (would love to have someday)
Once everyone has completed the first task, we process every card as a group. This is where it's critical that all stakeholders are collaborating. We want to meld the viewpoints of engineers, designers, domain experts, and product owners. We'll reorganize everything, write new cards as needed, throw cards away and ultimately end with a high level roadmap for the project.
The deliverable you'll walk away with is the digital N|W|D board or photos of what we've done in person. We'll also record all these cards on the Pivotal Tracker board, which you'll learn about later!
Job stories are the fundamental units of functionality we build and deliver. We think of them as vertical feature slices that stand on their own and add value to the end user. Job stories define a given situation, a user's motivation for acting within that situation, and the expected outcome of the action.
Using the "Jobs To Be Done" framework, we walk through the Job Stories, key activities and flows that users will take through the application. Then, we assemble them into a working list and prioritize them. This is a crucial step in defining the user experience and user interface, and it heavily informs the overall design of the application.
Key Workflows and Information Architecture
With any kind of form entry, users inevitably will encounter an error. Because a site map is limited to what's on screen, the presentation of that error and its resolution pathway are often overlooked.
A workflow map, on the other hand, includes real-world objects as well as everything that happens off screen, or off the core site map. So it covers not only the "Happy" paths but the "Sad" paths, too — which are a reality for any platform where information will be entered. As we work togehttp://www.verypossible.com/blog/what-are-see-do-maps-and-why-do-they-matterther we'll be able to identify the individual components within pages as well.
Each project has its own unique concerns and constraints. We do our best through this process to identify potential bottlenecks and roadblocks as early as possible. Oftentimes, this comes in the form of evaluating some external service or piece of software, but as your product complexity increases, we will need to do research spikes on the riskiest pieces, which may include:
- Does your project require machine learning? Are the tools you aim to use readily available as a service, or will we be needing to build models from scratch?
- Does your project involve a cryptocurrency or leverage a blockchain based technology of some kind? If so, are we aware of the legal and technical limitations of the current frameworks on the market?
- Does your project involve custom hardware development? Do you have manufacturing cost limitations? Have you identified a manufacturing partner? Are there strict security considerations?
We take whatever time is necessary to dig into the the specifics here and put together some initial suggested paths forward.
After we draft stories needed to accomplish user goals and business objectives, we estimate each job story with points. Points indicate the complexity of various job stories, as well as supporting detail. We break down more complex stories into smaller ones, reducing exposure to risk.
This provides us a clearer understanding of how much effort is required to build the pieces of the application. We also account for system concerns such as performance, compliance, scalability, fault tolerance, and maintainability. During development we will learn much more about how to build solutions to meet to user's goals, so we will continue refining stories and our release plan.
Product Development Roadmap
At this point, we look holistically at development needs. We build out a product development roadmap, organized into releases and weekly iterations so that the coming releases are clearly defined. We construct a release plan by sequencing work based on technical dependencies, risk, resource utilization, and just-in-time planning.
We've turned over most stones, and in some cases, performed research spikes to reduce uncertainty and verify assumptions. At this point, we should have a decent idea of what it will take to bring your vision to life. We will provide you with what we believe is your best path forward, along with some timing and cost estimates.
If a full-blown planning session is excessive for your needs, one of our other services might be a great way for us to get started working together!
If you have a preexisting application and are unsure whether to keep what you’ve got, clean up what's there, or scrap it for a totally new build, a Code Audit is the perfect service. Our engineers examine some or all of your code and check to see if it’s well written, unit tested, and functional. We have the ability to grade the code and provide a recommendation for the most cost-effective approach to proceed with iterative development.
A UX Audit is a valuable diagnostic tool for your product. Our experienced product designers take a look at your symptoms and use a methodical approach to uncover the source of the problem. At the end of the audit, you'll get actionable findings that you can implement right away.
Whether you are trying to raise money, demo a product concept to a client, or just want to see a concept come to life before coding, an Invision Prototype can be a powerful, cost-effective tool. We take our See|Do maps and apply high-fi designs to build a rich, clickable prototype that can bring your user experience to life.
Maybe you have an existing team, roadmap, and project management and you just need a lift or leadership on some of the technical specifics. We are happy to investigate where we can augment your existing team or roadmap and work alongside you in a short- to mid-term capacity.
Do you like to use these same frameworks and methodologies? We’d love to work with you. Tell us about a project you’re working on.