Product Design Workshop
Product discovery is the first step in building software that solves real-world problems. We use this process at kohactive to shape an idea into an executable plan. Our goal is to develop a shared understanding of the problem and identify the business opportunities.
All projects start with a product workshop, which utilizes design thinking principles to understand, validate, and test ideas. The purpose of the workshop is to set the stage for the product and answer some critical questions like what is the problem we're solving it, who are we solving this problem for, and what kind of solution are we creating. We'll use this information to interview users and begin the product development process.
We can host your team at our office or we can come to you, as long as there is a whiteboard and plenty of wall space, then we'll be good to go. It's important for all key stakeholders to be available for the workshop. Having decision makers present enables us to answer important questions and ensure the entire team has a shared understanding of the problem, goals, and process.
The project charter is how we define the project. It's a document that we create at the beginning of the project that contains the problem statement, timeline, players, and project goals. During the product workshop, we'll define all of these and finalize the document before we beginning real work on the project. The project charter helps us stay focused and ensures the product decisions we make fit in line with our charter.
1. Problem statement
All projects start with a problem, whether it's a business problem, process problem, or customer problem. This problem drives the need for the technology and should also drive the way we understand the project and create our solution.
The problem statement should be phrased as a question. The statement should provide clarity into the product that we're building. It imposes constraint so we can focus on why we are building this product. Some examples:
Problem statement: How can we improve our claims team productivity by automating tasks?
Problem statement: How can we provide live concert experiences to fans when they can't make it to the show?
Problem statement: How can we reduce the time the account management team spends creating shipment tracking spreadsheets for customers each day?
Problem statement: How can we reduce the amount of time hiring managers spend reviewing candidates that fail a background check?
A problem statement should be short, succinct, and focused. It should be human-centered since we're solving a problem for a particular user. The problem statement should be broad enough to allow for creative freedom but narrow enough to be manageable.
Another important goal of the workshop is to identify the timeline for the project. The timeline is not a schedule. It's a rough idea for how much time we want to invest into product to launch. While the project might have multiple phases that span over a year, it's important to identify when the first version should be completed. The timeline should help us contain the scope of work that we take on and avoid project bloat.
Another major component for success is defining all the players involved in the project team. For some teams it can be a single person but for larger organizations there can be various players involved from decision making to integration to operations to sales. Identifying these players upfront help us identify the various points-of-views as we develop the product.
Experts: Individuals within the organization who are subject-matter experts in the area of the business for which the product is intended.
Stakeholders: These individuals are from the business-side, they are usually in charge of the budget and have a business stake in the success of a project.
Builders: This is the team that is accountable of the execution of the product, they could be designers, developers, or project managers. This should also include any individuals with knowledge of other systems within the organization for which we must interface with.
End Users: These are the humans that will be using the final product, whether they are internal company users, customers, or regular people. While they are not formally part of the team, they will play a large role in helping us make informed decisions through user testing and interviews.
It's important to identify which category each of the players fit within. This helps us understand how we should make decisions and from which perspective we should view individual contributions.
4. Goals & Success Metrics
The last part of our charter identifies the goals for the project and how we are defining success. These should be scoped to the project, not necessarily the business goals, although these commonly overlap. Our goals should be achievable through the decisions we make building the product. Some examples:
Goal: Reduce the overall time it takes for a claims representative to assign and dispatch a contractor.
Goal: Customer should be able to track their shipments directly from their dashboard.
Goal: Reduce illegitimate applicant request by automating background checks within the hiring dashboard.
These are attainable goals for our project that the team has control over. A goal like "1,000 new users per week" is not something we can control. But simplifying the onboarding process can reduce abandonment and, in turn, lead to one thousand new users per week.
For each of our goals, we'll set a success metric to identify if we've hit our goal or not. For example:
Success: Average time to get a confirmed contractor dispatched is reduced to from 5 hours to 1 hour.
Success: Reduce need for account team to send shipment tracking spreadsheets by 50%.
Success: Number of candidates dropped for failing background checks is reduced by 85%.
Success metrics should be based on measurable data. If we're going to reduce contractor dispatching from 5 hours to 1 then we must have solid data that on what's involved in the dispatching process in order to achieve our goals.
These goals must match up with our problem statement. If any goals or success metrics don't align with the problem statement then it must be removed or the statement must be accommodate the new direction.
The next part of our discovery process is identifying the personas of users in our system. These don’t represent real people, but a representation of individuals that will be using your product. We use this personas to identify whether the decisions we make about the product provide real value for our users. Personas are composed of four things:
We typically give our personas names like “Jane the customer”, “Brian the claims representative”, or “Samantha the hiring manager”.
Attributes are used to describe the persona, we use things like age, gender, economic status as well as more complex descriptors like their comfort level with technology or their speed in making decisions.
What motivates a given persona? What are they looking for? What are they looking to do? What are their needs? These are important questions we must answer in order to understand as we make product decisions.
We’re building software for humans. Understanding these humans is essential in building successful products. By creating these personas, we can always ask ourselves if our decisions will positively impact our users and add value for them.
User Journey Mapping
Once we’ve identified our user personas, we can begin create user journey maps. These are diagrams that illustrate the steps involved in achieving a goal. These journeys can be an in-app experience, a cross-application experience or even a cross-device experience.
User journeys can be simple or complicated maps of steps involved in achieving a particular goal. Since we’ve identified our persona’s goals and motivations, we can map out the most important tasks that we can want solve. Here is an example of a simple user flow:
The user journey map starts on the whiteboard and ends in a document we create to set the stage for our design process. There are a few important things to identify while creating user journeys.
Journey’s are broken into tasks that a user wants to accomplish. A task can be simple or complicated. In our example above, we have two primary tasks: an admin wants to invite a customer to the portal and a customer wants to set up their account. We create a single customer journey to visualize the life cycle for this journey.
Tasks should be aligned with our problem statement and at least one of the goals we’ve identified. If a task comes up that doesn't fit into our project charter then it should be dropped or placed in the icebox for later.
Some examples are:
Task: Customer can create a new claim.
Task: Claims representatives can send claim document for e-signature.
Task: Admin can override the contractor assigned to a claim.
Task: Admin can add a new customer to the system.
Each task is composed of activities that is required for a user to accomplish a task. For example, here’s a set of activities a user would have to take to set up their account:
- Click the link from the invite email
- Create their login
- Fill in their account profile details
- Review/approve customer details
- Invite their colleagues to the portal
- Land on new dashboard
These activities shouldn’t be too technical or complicated. Anybody on the team should be able to describe a given user flow. It’s important for us to pull in our Experts during this phase to help us understand what are all of the obstacles or situations that we’ll want to handle.
Occasionally there will be diviations in the flow, perhaps there are two options and the following flows is dependant on which option was selected. We’ll diagram these all out during this mapping session. Also, many of these tasks become chainable, for example a user might sign up, create a new collection of documents and then share with a friend. We would break this down into multiple tasks and then combine them into a single flow.
Our customer journey mapping will be made up of multiple flows that address the tasks and activities involved in achieving the goals for a given user.
User journey mapping will spark quite a bit of debate. The facilitator of the workshop is responsible for ensuring that we’re focused and tackling the tasks that align with our project charter.
Lastly, journey mapping is a blueprint for our project scope. It helps us with initial estimations as it present clarity into the product that we’re building. This is a good opportunity to address potential difficulties, obstacles, or roadblocks. As we finalize the journey maps, we’ll decide on which are the most important and immediately applicable to our charter and use those to kickstart the product development.
Once we’ve identified our personas and mapped out our customer journeys, we can begin our initial user interviews. Working with your team, we’ll schedule interviews with the End Users. Our goal is to understand what their needs are, what currently works for them, what doesn’t, and answer other critical questions.
In some cases, we may mockup very simple prototypes of our user journey maps to get direct feedback on our understanding of the problem and potential solution.
User interviews help us ensure that we are targeting the right problem to solve. The interview responses should reinforce work we’ve documented in the project charter and through our journey mapping. If anything seems off or we get negative feedback then it might be a good opportunity to pump the breaks and reassess our problem statement and discovery.
These interviews don’t necessarily happen during the workshop. Typically we schedule them as the last day of the workshop but don’t require the entire team to be present. We’ll provide a report after the interviews are completed with an overview of the insights gathered.
Once we’ve completed our journey maps and received positive feedback from user interviews then we’re ready to start release planning. This phase helps us prioritize the order of the features that are to be built throughout the project. We’ll organize them into milestones across the project timeline. This will help the team, stakeholders, and business owners understand the overall evolution of the project.
The release plan also helps us identify integration points with other teams and coordinate to ensure we don’t have to slow things down because of poor planning.
The release plan should be approved by the primary stakeholder based on business needs and opportunity.
Release planning does not have to happen during our workshop. We typically start discussing these in the workshop and then later refine and get approval within a few days.
We’ve been conducting product workshops over the past five years and have learned quite a bit during this process. The following are some best practices we like to follow.
Workshops can be overwhelming, especially when we try to go at it for a few full days. We find it’s best to do a series of half-days but we understand that sometimes this is not always possible. We don’t have a set number of days that is required but they are typically between two or three days. Starting at 9am and going until lunch each day is ideal. We’ll work for 50 minutes and take a 10 minute break for bathroom, emails, or a snack.
During the workshop, our primary tools are the whiteboard, post-it notes, and paper. We’ll have plenty of these available as we sketch ideas, take notes, and share our ideas. Eventually, all of the information will makes it way to a digital format.
While the workshop is a long, multi-day process, it’s key to minimize distractions. We recommend that laptops and phone stay off and away so we can focus. We take breaks every hour so there’s plenty of time to catch up on emails and conversations. A focused team can help us gain momentum and work productively.
At the end of each day we conclude with a quick retrospective of the day. The facilitator will provide a recap of what we’ve covered for the day and what the agenda for the next day will be.