“If you are not embarrassed by the first version of your product, you’ve launched too late.”
– Reid Hoffman, Founder of LinkedIn
Reid Hoffman, the founder of LinkedIn (recently acquired by Microsoft for $26.2 billion), famously said “If you are not embarrassed by the first version of your product, you’ve launched too late.” As a Product Manager, though, especially in enterprise, a truly embarrassing launch could be at its best difficult to reverse and at its worst a disaster at scale — for customers, for the business, and for the team. On top of that, enterprise development release cycles can often be too long for useful iterations and learning before launch.
This does not mean that Product Managers have to toss lean principles out the window, though. Development time is a precious resource. If it is so precious, why are enterprise teams wasting so much of it? To be more efficient and responsive, your team should consider adopting and adapting the “design sprint.”
The Design Sprint is a process developed by teams at Google and Google Ventures to answer critical business questions and validate prototypes in just five days without using developer resources. The recently released, popular book on the subject Sprint, written by Jake Knapp, John Zeratsky, and Braden Kowitz, mainly provides examples from startup teams, but design sprints have been used successfully in large enterprises and corporate environments for some time. Enterprise sprints can be just as effective as startup sprints, bringing positive change not only to how the product team works, but also to how the organization thinks about products and users.
How Can Design Sprints Work for Enterprise Teams?
Most enterprise teams, and even larger “startup” teams, bring a healthy amount of skepticism to the idea of design sprints. Taking busy people out of their day-to-day work to focus on a single problem and come to a solution in a short amount of time can either seem like a fantasy, a waste of time, or just a distraction from the real job of building and growing products. The fact is, however, that design sprints are not only more efficient and produce better design choices, but require fewer resources than testing for feedback at product launch. They also have the benefit of gaining cross-team buy-in for projects, getting everyone on the same page and contributing, while avoiding the typical drawn-out design-by-committee that can occur in large teams.
There are many great resources and detailed step-by-steps on how to run a sprint, including the book Sprint and Google Ventures own website on design sprints. I will focus this article on the basics and the areas where enterprise teams will have special considerations and need to adapt.
The Standard Sprint
Google did a lot of internal research running sprints over the past 5 years with different team sizes, durations, and processes before coming to the 5-day design sprint methodology outlined in Sprint. Let’s start with the basic sprint, then we can address the issues that your sprint team might face in an enterprise environment and how you can adapt to those.
The sprint is a 5-day process with a cross-functional team, led by a “sprint master.” The purpose is to have prototypes of your product, features, or experience validated by real users at the end of the 5th day. No matter how you adapt your sprint, it is always comprised of 6 stages: Plan, Understand, Sketch, Decide, Prototype, and Validate.
Components of a Design Sprint
The sprint master is an important component, as having a single person responsible for running the sprint and the team leads to higher satisfaction and better results.
In an enterprise environment, who you select as sprint master is important. Typically, there is more than one stakeholder who can decide the outcome of a project. Also, buy-in from someone higher-up or your peers might be important. In these cases, it may be best to assign the sprint master role to someone else who has decision-making power in addition to yourself. For my first sprint, I casually sent “feeler” emails out with articles about sprints to fellow Product Managers, and quickly found a PM who was excited about the idea. Letting another Product Manager lead the sprint with my support accomplished two things: First, that PM felt more engaged and invested in the process, making him a fellow champion to inspire the team. Second, the rest of the team felt more trust in the process since there were several of us on board with the concept.
In the Planning stage of the sprint, the sprint master has to clearly identify the challenge that the team will be solving. There are many goals the team could be thinking about, and a lack of focus can derail a sprint. For instance, in one of my first design sprints, the sprint master decided to focus 100% on improving client trust and conversion, based on the quarterly goals in that area, while leaving out other potentially distracting goals, such as effects on conversion rates of other user types. This clarity ensured everyone was working toward one clear and narrow-enough goal.
In an enterprise environment, there are several departments that typically have to sign off on a proposed product change or launch, such as legal, marketing, etc. Focusing the goal will ensure that there is no further distraction besides the bare minimum launch checklist.
The best way to plan and outline the goal for the sprint is in a design brief. The brief should define the challenge and goals of the sprint, as well as a timeline for the launch or deadline for the deliverable.
During the Planning stage, you will also want to select and invite your team to the sprint and schedule User Testing ahead of time. Selecting your team is discussed in the next section. User testers will usually need advanced notice and you will need them to validate your prototypes on the final day. This also ensures that the sprint will progress and give your team a sense of urgency to produce your prototypes by the deadline.
Finally, you will want to collect as much user research, data, business metrics, and insight you can before the sprint. A PowerPoint deck will usually be useful for the team. Ensure various departments bring their own data and insights prepared for the Understand stage.
The team is a key component of a successful sprint. Sprint suggests that 5 days is such a short amount of time that it is easier to bring members of other teams to a sprint. In an enterprise environment, trying to get the CEO, VP, designer, engineer, and sales managers to dedicate 5 days is going to be a challenge unless you have strict top-down buy-in. This is even a challenge in startups. At HourlyNerd, we had to design the sprint so that our CEO was only present for the most important parts. We also made some components of the sprint asynchronous (e.g. everyone could go home and work on their separate parts before Day 3 on their own schedule) to accommodate sales calls, design deliverables, and other meetings. If you understand the purpose of each stage of the sprint and keep the deadline short enough (no more than 10 days is best) to drive urgency, you can adapt your sprint and have a successful outcome with a cross-functional team.
Since who participates in the design sprint can be critical to its success, it is often useful to have a short meeting with the main players to discuss the sprint and align on the process that works best for you. For my first sprint, I wanted my VP of Product and CEO present, so we met beforehand to give a quick briefing on the purpose, benefits, and components of a design sprint. This led to two adaptations: First, our CEO and VP Product would only come to the full Sketch and Decide stages of the sprint, while the Understand, Prototype and Validate stages only required them for quick meetings to check in and debrief. Second, our designer noted that the in-person, high-pressure sketch process would not be the best way for everyone to produce good contributions, so we left a 36-hour gap before this stage so individuals could produce their sketches when and where they wanted.
On Day 1 of a sprint, the purpose is to align everyone in the team on the goal and purpose of the sprint. It is important to present and align on all of the data and insights that are usually siloed in various teams and in people’s minds before moving into opinions and debate. One key component of this stage are the “Lightning Talks,” where members of each team discuss the goals and data from different perspectives. The CEO or revenue officer might discuss business goals, while Engineering may discuss what is possible (especially important in enterprise with legacy architecture or permissions requirements), and the User Perspective may come from actually having potential users or customers in the sprint team. If you cannot find actual users to attend, a User Researcher or a Product Manager who has talked to users and collected insights and user data should present this perspective.
Unbiased Insights — Just the Facts
In my personal experience in meetings, both in corporate and startup settings, it is important to present data and insights upfront with as little bias or assumption as possible. By telling teams to give unbiased facts and insights before their Lightning Talks, it prevents needless arguing over details until all of the data and insights from each team’s perspective is on the table and can be discussed with full knowledge of the facts. This is a great opportunity to break down silos in an enterprise environment and can have positive effects beyond the sprint itself.
The Define Stage of a design sprint is where the goals, metrics, or even the specific features and user journeys are decided. This can be a contentious stage in an enterprise environment since different departments will see the goals and user journey differently. It is important to really spend the effort to define these goals, metrics, and journeys in a way that everyone understands before the Diverge stage.
The Diverge stage is the most participative and creative stage. The team individually provides solutions, avoiding groupthink and design-by-committee. It is important to have everyone contribute to this stage by bringing their own representation of the problem’s solution. Sprint and Google Venture’s website both outline activities to facilitate this stage. In an enterprise environment, if you cannot get everyone in the same room at the same time all day, you may have to adapt. I had mentioned that we left a 36 hour buffer to do some of this on our own time, but insisted that the CEO and VP Product participate here. Nobody should opt out of this stage as creative skills are not as important as the diverse set of valuable approaches to the problem. To alleviate concerns, remind the team that any approach they put forward will be tested by real users before it ever gets to development.
In the Decide stage, the sprint team members have a means of voting on different parts of everyone’s solutions to find themes and patterns. Voting is typically done by placing all of the ideas, sketches, and wireframes on a board, then giving each team member a certain number of colored dots to vote on the parts they like.
A great way to get buy-in from important decision-makers, such as the CEO, is to give them more colored dots to vote with to reflect their influence on the final decision. Some CEOs or VPs would not want this at all, and it may be best to let this person vote last to prevent biasing the rest of the team’s votes. Discussing this beforehand is best and depends on your team’s dynamics. One benefit of giving leadership more votes is to provide confidence in the team that the chosen ideas will have approval to actually move forward.
At this stage, the ideas are likely fairly raw, so it is about deliberation, refining the ideas into something more coherent and understandable, and selecting one or multiple choices for the product solution to move into the Prototyping stage. The makeup of your team’s decision makers will define how the Decide stage goes, but I have found that senior management might even trust you to make the decisions without them. Since everyone has put in their solutions and presented their data in previous stages, a sober discussion to pick one or a few solutions to test is easier to swallow than if everyone’s voice was not heard and honestly considered.
This stage has many possible activities discussed in other resources, including “How Might We” affinity mapping and more. Google Ventures, Sprint, and even Udacity’s Product Design video course with a module on design sprints would be great resources to learn specific exercises.
Sometimes the politics of a larger organization may require the sprint master, Product Manager, or CEO to make the final call themselves on which solutions actually make it to the Prototype stage. It is important, however, to avoid allowing one voice to overpower other opinions, and the sprint master should keep control and moderate the team. Individuals who are considered “experts” are not always the ones with the best or right solution. As a PM, I would personally work with the UX designer to decide on the best solution after taking into consideration the voting and discussion that came during the Decide stage.
Even after it tests well in user studies and with other teams, an idea will still need approval from senior managers based on its alignment with their strategy. It is tempting to only select ideas to test that management would like, but the exercise is also meant to reveal the truth about what users really want.
A PM running a sprint will want to mitigate any conflict here, but it’s important to retain the integrity of a valid idea generated by the team. It is crucial that you identify which management concerns might be truly legitimate and translate those concerns to the team. For instance, for a talent marketplace, making a list of all user profiles public and browsable might be considered a great way to attract clients and instill trust in the quality and quantity of talent on the platform. A senior manager may point out, however, that it conflicts with a feature that “unlocks” this sort of browsing at a Premium membership level. As a PM, you will want to communicate the tradeoffs as a team and maybe align on a browsable list of candidates on one page, where “X thousand” more candidates can be unlocked with Premium subscriptions. This accomplishes two high-level interests: cultivating the trust of clients and keeping company’s financial goals at the forefront.
Once you’ve made a decision about X, you can then pick the solutions and draw up storyboards to move on to the Prototype stage.
In certain enterprises, putting wireframes, mockups, and prototypes in front of users can be a bit tricky. A good product owner will understand what fidelity of prototype is user-ready, but they should not compromise on the 1, maybe 2-day turnaround on these prototypes.
GV does a great job of providing ideas on how to make high-fidelity, interactive prototypes quickly and easily. Tools like InVision (who have a great post on using InVision in a 3-day Design Sprint variant) and even Keynote (see an example sprint using Keynote prototypes) can provide realistic interactions using mockups with no development time. If you have a front-end developer at hand, they may be able to make an interactive prototype locally very quickly, as well, maybe using a script that edits your current user interface superficially in the browser. Before moving to the final prototype, of course, a storyboard or wireframe flow should be created with the UX designer or on your own. Once the Prototype is done, it is time for the Validate stage.
Most enterprises find out if they have the right product and if that product is usable once they have launched. At that point, they are left with tech debt, legacy, or vestigial features, and lost developer hours that cannot be taken back. The Validate stage of the design sprint will have you put the selected 1 to 3 prototypes in front of users to validate which is best and if it is usable.
This might be in comparison to your current product version, if there is one.
There are plenty of resources online for conducting user research, usability studies, and more (see my 15 Product Management Books for Learning UX Design). Google Ventures provides some great articles on the subject of user testing in design sprints, as well. If you have trouble finding users, you can always use sites that source and record user testing sessions with NDA and confidentiality agreements, such as UserTesting.
Remember that the CEO or Director will likely have the final say. Even a prototype that tests well might be turned down for strategy or budget reasons. Ensure that you learn as much as you can, whether or not your prototypes are the right ones after user testing. This will often mean you can identify changes and iterate on the prototypes for further rounds of user tests. In my experience, it can take two or three rounds of prototype testing before coming to a launch-ready solution to start developing. Luckily, this iteration process does not always require the whole team.
Adapt The Sprint For Your Team
Every team is different and it can be tough to get everyone in one room for a week or tackle a problem in exactly 5 days. Ideally you can run a sprint as suggested, but if you have to, you can modularize the important stages of the sprint. This can work as long as you keep the principles of first aligning on unbiased data, having everyone provide their individual solutions, deciding on the best ones, then prototyping quickly to learn from real user tests. Not only will your team learn that decisions can be made quickly and efficiently, sprints can be a catalyst to break down barriers and politics between siloed groups to build a more effective product-making organization.
Now, Run a Sprint!
Now that you know how sprints can work for Enterprise, here are a few resources to help guide you:
- Sprint the book by Jake Knapp
- Udacity’s Product Design Course Co-Created with Google
- Google Ventures original Design Sprint site
- & Market Gravity’s Medium story on “Applying GV Sprint in a Corporate Environment”
- Google’s Design Sprint Methods Guidebook
Good luck and happy sprinting! Feel free to post your stories below in the comments section.