Agile Product Design
Agile product design is all about getting from product ideas to product choices. It’s a process we’ve used many times at DevMynd to help get the product out of a customer’s head and into an executable plan. This guidebook serves as an overview of that process, and in true agile fashion is a living document that we regularly review and update based on our learning.
The following steps comprise what we call “Agile Product Design”. It’s “Agile” because this process is not meant to be rigid. The structure here is more akin to a bouncy castle than a concrete bunker, it’s intended to flex. For some teams and individuals various parts of the process will be difficult, others will just click. For this reason we facilitate the process and curate the conversation so it stays productive and on target.
Stage 1: Chartering
The first milestone is to create a charter which will serve as a set of anchor tenants for an initiative. We often talk about how the word “Charter” seems so imperious and heavy, but it’s sort of the right word. It’s the “We the people…” for the project, it doesn’t say what we’re going to build, or how, it says why.
It’s helpful to think about chartering as an activity that can happen several times over the course of an effort. It’s conceivable that an overall initiative would be broken down into multiple projects each with their own version of the charter.
The charter statement is a short paragraph (1-3 sentences at most), maybe bullet points, that explain the reason we’re building something. These reasons could be business related, but are more effective if they’re focused around the end-user or consumer, even if that’s an internal entity. Some examples:
STATEMENT: Musician’s Marketplace will provide a marketplace for musician’s to buy and sell used instruments and equipment.
An online e-commerce platform where musician’s can post advertisements for things they’d like to sell and others can purchase the items.
STATEMENT: The Global Reporting project provides insight to customers into the condition and maintenance investment of their global vehicle fleet. These insights will help customers make better decisions about maintenance providers and vehicle turnover.
A system at a fleet management company which provides a dashboard for customers to view the condition of their fleet.
These short statements provide high-level boundaries to the goals of the project. The first statement, for example, doesn’t mention anything about buying or selling new items from manufacturers. When someone in the chartering session brings up the idea: “hey, maybe we should allow brands to sell direct”, our charter statement helps us keep focused and avoid the rabbit trail. The statement can always be changed, but the group must agree and understand the implications of the change.
Similarly, in the second example, we specifically talk about the product being global. This will force the team to discuss the nuances of collecting the necessary data from various sources around the world. It may come to light that this goal is too lofty and the charter will be amended to be focused around specific countries. It’s all about driving discussion and defining basic constraints.
Another major component of the charter is setting the timeline, by this we mean a rough idea of when we want the project to be completed. This is NOT an estimate of how long a given amount of scope will take to build, it IS a constraint that helps us determine if we’re taking on too much. Often we’ll put this on the board in units of months and it should be driven, if possible, by the business needs – e.g. “We should try and get this done before the summer sales cycle, so maybe 3 months.”
The last major component of the charter is identifying who the players are on the project team. This includes anyone who has a stake in deciding what the product will be, how it will be integrated with the company’s product offerings, operations, and sales. Identifying the players in the decision making process helps us to keep all points-of-view in mind when making product choices.
When the team of stakeholders is large (4-5+) we like to break down which stakeholders have more sway in decisions. For example, if there are sales people in the room, perhaps their input is more or less critical than the operations team. Putting some rough percentages next to names helps to identify who should have the lion’s share of influence.
Sometimes it’s also helpful to break down the players into three groups not based on roles but more on personality:
INFORMED: individuals who are subject-matter experts in the area of the business for which the product is intended.
INVESTED: these people are driving from the business side, they are often in charge of the budget and have a business stake in the success of the project.
BUILDERS: the part of the team that’s accountable for execution, they could be developers, designers, or project managers and have direct implementation knowledge of other systems in the company.
Knowing which of the three categorizes a player helps to make sure that we consider the product from all angles. It also furthers the goal of putting a spotlight on the voices in the room that should have the most driving guidance.
Stage 2: Goals & Success Criteria
Once the charter is complete it’s time to get down to the next layer of detail, defining goals and success criteria. In this context, goals are specific goals of the project, not necessarily business goals (though there may be overlap). What we mean here are goals that a product can achieve, goals that we can influence. Some example goals:
GOAL: Reduce the overall time it takes to on-board a new account through the admin system.
GOAL: Users should be able to self-serve for scheduling appointments.
GOAL: Teachers can easily create lesson plans from previous versions.
These are attainable product goals that the implementation has control over. These are not things like “Sign up 200 new users on day one”, which are side-effects of our work, not things we can force to happen.
We counter these goals with success criteria that tell us when we’ve achieved the goals.
SUCCESS: Back-office time to register a new customer is reduced from 3 days to 1 day.
SUCCESS: Customer service calls to schedule appointments are reduced by 50%.
SUCCESS: A teacher can create a lesson plan from a previous one in less than 3 steps.
These goals must match up to the charter statement. If any goal or success measure is defined which is not in support of the charter statement then it should either be removed, or the statement should be adjusted to cover the new intent of the project.
Likewise, as we get into story mapping later on in the process, we’ll use these goals and success criteria to constrain our stories.
Stage 3: Personas
The next thing is to discover is a set of personas which represent the users of the system. Don’t think of the real people in these roles, but the archetypes of individuals who will use the product. There are two parts to a persona: attributes, and added value. We typically like to give our personas a name, “Jill the existing user”, “Mike the operations guy”, “Ann the shopper”, “Craig the executive”. This makes it much easier to talk about these actors when evaluating whether stories really solve the problems of a particular type of user.
A persona’s attributes are the things that characterize them and may influence how they use the system. Attributes could be things as simple as age, gender, and economic status. They could be more complex such as a person’s comfort level with technology, someone who is good at math and likes numbers vs. someone who does not, a person who makes decisions quickly or takes their time. All of these help us question ourselves when we get to writing stories.
The second component of a persona is added value. By this we mean the value that the product adds to a given type of user. For example, if we go back to our goals, we can think of the value added to “Susan the teacher” being that she spends less time building new lesson plans. Or for “Pete the customer service rep” spending less time on trivial appointment scheduling calls and more with customers who have more complex questions. See how it all ties together?
Stage 4: Story Mapping
Here’s where the real work begins. The idea of story mapping is to organize groups of stories around a task (something a user want’s to accomplish) and a set of activities (things that the user must do to accomplish the task).
Sometimes a picture is worth a thousand words so here’s a few examples of what we’re talking about:
Let’s dissect this a bit.
As you can see, each “stream” of cards begins with a task card. The task is a target for the user, it’s something they want to achieve in the system. The task could be something simple and will have just a few activities beneath it, or it could be very complex (which may mean it should be broken down).
Tasks should align with the charter statement, and at least one of the goals from the second stage. If someone starts talking about a task that doesn’t fit it means that it shouldn’t be on the board, or that the charter and goals should be updated. Tasks that don’t fit with the charter may be kept around in the parking lot (described later) so that we retain all the ideas but focus on what’s germane to the charter.
Some example tasks:
TASK: Sign up
TASK: Search for products
TASK: View applicant details
TASK: Create post
TASK: Upload incident photos
Beneath each task, we see a number of activity cards. These are the “how” of accomplishing the task. The idea is to break down the task into fairly fine-grained activities. Here’s an example of a series of activities for the “Upload incident photos” task from above:
ACTIVITY: Search for incident by keyword
ALTERNATE: Search for incident by customer and date range
ACTIVITY: View incident details
ACTIVITY: Upload incident photo(s)
ACTIVITY: See list of uploaded photos on incident details
As you can see, none of these are too technical and don’t talk about navigation or clicking on buttons, they’re as close to the business steps as possible – further details about implementation will come later.
Occasionally, we hit upon an activity that’s something the system does. In the photo, you can see one of the cards turned at a 45° angle. These cards are system activities and even though they are somewhat technical, we try not to talk about implementation. For example, at one step in a process the system may send out an email so the system activity card would indicate this, but it doesn’t really need to say that this is done through a background message queue.
In some cases, there will be more than one path to accomplish a task. This is where we see alternate activities come into play. These cards are placed beneath the activity from which they diverge.
Lastly, these streams of activities will often connect to one another. As one stream ends, the user rolls into another task. Activity cards which kick-off or overlap with another task will have a dot in the corner and we may write the name of the task to which they connect if it is not obvious.
That’s story mapping in a nut shell. In practice there are a lot of nuances to how we do this, but the ultimate goal is to define the breadth of the system and extract enough detail to eventually plan a release and do some initial estimation. Story mapping can spark a lot of debate, and the facilitator’s job is to compel the group forward without leading the discussion.
Story mapping should take up the bulk of the time in these sessions. In large systems it can take multiple days to get through the process. It’s important to keep an eye on the charter statement, goals, and personas throughout story mapping to insure that we don’e veer off course. If we discover we really do want to take a different course, then we update the previous stages.
Stage 5: Slicing
Once story mapping is complete we start to get more practical about what we’re really going to build. Throughout story mapping we will have put a lot of tasks and activities on the board that are nice-to-haves, or things that can be deferred to future releases. In the slicing stage, we want to slice out activities that aren’t essential for the most near-term phase of development.
Slicing is generally a fairly quick process and is done by taking away cards that should not be done in the near-term phase of development. This will often kick off lively discussions as various business drivers compete but the key is to keep the timeline and goals from the charter in mind. If there are technical folks in the room, this is one time when it’s alright for them to comment on feasibility. If the timeline doesn’t hold, either change it or remove more from the board.
Stage 6: Testing
The testing stage is where our personas come back into the mix. The goal of testing is to walk through our story map and consider each task and stream of activities with each persona in mind. As we “put on the hat” of each persona, we’ll talk through the activities and validate that this set of activities makes sense for the persona.
Obviously, this requires a bit of imagination. Sometimes we’ll realize we don’t know enough about a persona to complete this task, or we’ll find ourselves making a lot of assumptions. These moments should key us into the fact that we may need to do some user testing at some point and get real people to help us validate our concepts.
Once complete, the testing stage should have verified that all the cards on the board make sense for all of the personas. We may discover new personas in this process, or we may discover that some persona’s do not have a place in the project. We’ll go back and update personas and the charter if necessary.
Stage 7: Release Planning
This stage is something that’s generally done outside of the product design meetings. We’re including it here because it primarily uses the output of the design process and may feed back into the discussion after the fact. The goal of release planning is to order the tasks that are to be built and organize them into milestones. We don’t do any estimation here, just order them based on business value with dependencies in mind.
The release plan helps us figure out integration points and coordinate with other teams in the enterprise. It highlights the different skill sets that will be needed on the implementation team throughout the effort and is vital in determining the staffing levels over time.
Because this process is driven by people, you can imagine there are a lot of things that can go awry. Over the years, we’ve picked up a few best practices for running Agile Product Design efforts.
Facilitator & Scribe
There are two key roles for running a design effort: facilitator and scribe. The facilitator’s role is to guide the discussion and curate what is put on the board. The facilitator should not lead the discussion and should keep opinions and their own ideas to a minimum. The facilitator will however ask lots of questions and will help refine the language that’s captured so that it is concise and meaningful.
The scribe’s roll is to record everything. This is the one person in the room that’s allowed to have a computer and should keep very detailed notes. Between what is captured on whiteboards and post-its, and what the scribe records, a very complete picture of the discussion should be retained.
It’s best to break down the effort into a series of half-day meetings, ideally held from 9am to noon as people are more fresh in the morning. We set a pomodoro timer for 50 minutes and the end take a 10 minute break, repeating this cycle until lunch. This gives us three very focused periods of time with 2 decent breaks in-between for visiting the facilities or answering email. During the afternoon, the facilitator and the scribe will take some time to compare notes, refine language, discuss the plan for the following day, and identify areas of ambiguity that need addressing.
Eventually stories will be put into an electronic form, but during these meetings the best tools are physical. We use giant post-it sheets for the chartering, goals/success, and persona components. For story mapping we prefer small post-its in three colors (one for tasks, one for activities, and one for other notes and parking lot items).
The Parking Lot
Throughout this process, inevitably someone will have a great idea that has nothing to do with the particular product. Or, someone will interject something that they feel very passionate about, but nobody else does. It’s important not to lose these thoughts. A portion of the space is reserved for a parking lot where these ideas are kept on post-its. In doing so, the idea is retained, and if needed can come back into the process.
Minimizing distractions is key during the morning meetings. We prefer that folks do NOT bring laptops or tablets into the room and turn their phones off. The breaks at the end of each hour are great for catching up on communication but during the meetings we’re after momentum.
We love it when technical folks join these sessions, as long as they can’t stop being technical when they’re in the room. When the discussion gets technical it tends to bog down the group, especially for the non-technical folks. The facilitator should be quick to shut down any topic that gets too focused on implementation or technology.
It’s helpful at the end of each day for the entire team to do a quick retrospective. This shouldn’t be more than 10-15 meeting and should not reopen discussions from earlier in the day. This meeting is intended purely to let everyone know where we are in the process, what was accimplished today, and to set a rough agenda for tomorrow.