What Everybody Should Know About Product Management Design Sprints
One of the product management principles is being nimble. In the past, firms would set long-term goals and detailed plans that would oversee processes for a sizable period: weeks, months or even years!
However, today’s consumer cycle and the digital revolution demand product teams that are ready to juggle and switch between tasks very quickly. This is not because non-physical products are always in “beta mode”: actually, it is this modular aspect that makes certain applications very powerful.
The biggest success stories, from Amazon to Google, are examples of ventures into new markets from established solutions; thanks to their ability to improvise and reap gains from innovation. In order to do this, you need teams who are familiar with methods like “agile“, which facilitate collaborative teams and a quickfire approach to problem-solving.
But, most of all, you must know how to be efficient in your product design.
This is where the art of sprints becomes vital. Turn it to your advantage with this guide.
The Product Management Design Sprints Essentials
Not everyone in tech works using sprints, but almost all of them will know what they entail.
Obviously, every organization has their own version, fit for their product, sector and staff. However, the key principle behind a Sprint is to save steps in product development and release. A short-time constraint is necessary and it highlights the “survivalist” nature of the Sprint: only what is useful will be kept in the end.
Equally, the practice is best-suited to small teams of no more than ten participants. After all, we are talking about guerrilla-style mobilization: that is impossible when you are trying to lead a whole army into battle.
Once these two conditions are set (time and team), the next best step is to formalize some sort of plan. It does not need to be a finalized map, but it needs at least key steps and an overall goal defined. Otherwise, how will you measure the sprint’s success? That said, make sure that these targets are all adaptable and be ready to discard them if anything unexpected should happen.
Every day, you should make sure that the whole team meets to exchange impressions. This is supposed to be an open exercise: if you are in a management position, try and encourage usually silent voices to speak up.
Any documents tracking progress across functionalities cannot be a secret: they must be shared with everybody and updated correspondingly.
One fundamental aspect to remember is your special position as Product Manager. Of course, sprints can be led by any type of professional. However, PMs are particularly well-suited for the task: they work at the intersection of many vital functions (design, development, user research, marketing, etc.) and thus they are perfect for “translating” doubts and achievements across teams.
Next, educate, educate and educate. Yes, you are the product’s key representative. You are the customer’s voice. Many teams who are not in touch with the public tend to forget this. They will focus on solving technical hurdles. Your job as “evangelist” is to keep everyone’s mind on the product.
You can share with the least-commercially minded members of the team materials such as surveys, customer feedback and other materials that remind them of who you are ultimately working for.
Finally: keep morale high! Whether you are at a startup or bigger organization, it is likely that your team is sacrificing a lot to complete the Sprint. No better reason to stress team cohesion before, during and after the Sprint. Some simple suggestions include setting up team lunches at the beginning and the end; establishing compulsory breaks for coffee and doughnuts; steering meetings where everyone shares something they learnt that day…
All in all, you are expecting a lot from your team; but they also expect a lot from you!
The Practicalities of Product Management Design Sprints
Taking an ever close look into PM Design Sprints will help flesh out some examples.
Their most common application divides it into five steps or “days”. They do not need to take place during literal days; this is just a way of dividing the work neatly. Here, we have added a “zero” step, something very important that often gets ignored!
This zero step involves the decision to implement the Sprint methodology. In a way, most companies that embark on activities that require short-term dedication are already informally conducting sprints. However, if you make the conscious decision of using it, you must understand why. Is it because the competition, or one of the greats (like Google) is doing it? Is it because you think that you need a change?
Or is it because your team has been educated in the principles of the Sprint, and can benefit from it? Gaining alignment is highly important before starting.
Now, Day 1 involves reflecting on what you are going to do. Going back to the general Sprint principles discussed above, it hinges on setting up a direction of travel. As you are supposed to be a good PM, defining user flows and needs is fundamental. Everyone in the team should start developing at least a fuzzy idea of the new product/feature will do for the user.
It is very stereotypical to graphically depict this day with some sort of post-it-on-a-whiteboard generic photo: this is because the method works! Opening up a planning forum, particularly in offices where everyone is usually focused on executing rather than conceiving; can be a very powerful experiment.
Other suggested activities, which apply to Sprints on existing products, can be a controlled assessment of everything the software or app can offer. This means that team members will try their best to “break” and push your product to the limits.
It is within these participative, extreme and fun conditions where inspiration for the next step will surely emerge.
Day 2 requires that everyone pushes creativity to the max. It is probably the most individual milestone, as it requires that all team members focus on their impressions from the previous exercise. Travelling from the overall idea, they must zoom-in to the space they “own” in development (design, coding, marketing…) and reflect on their idea of a worthwhile user improvement.
Most likely, some team members will feel more confident than others to develop an individual product vision. Do not be afraid to intervene as a Product Manager and facilitate this task by providing examples, sharing your impressions and basically engaging everyone. Already working on generating alignment will save you a lot of time in the following stage.
Day 3 is D-day: decision day. This is where everyone must leave their particular objections aside to generate a consensus, or at least an alignment. The main task at this point toelaborate a detailed roadmap so everyone is on the same page.
It might be useful now to divide people among functionalities, because while diverse perspectives are welcome, different teams face different obstacles. It will not be a productive meeting to have everyone raising points that are, frankly, only important for a few participants. That said, keep channels open and remember to have some sort of physical or digital board where progress is visibly updated.
Day 4 is where you put in all the work. This is where teams translate all the planing into action. But this is not your regular workday. This is a Sprint!
Remember to remain agile and in communication. Once you get lost in your work, it can be very easy to forget how to work in collaboration. It might be useful to set up “mixed teams” (marketers and developers, designers and salespeople) that must report to each other at agreed times; usually, end of the day. Actually, the reason why you should be flexible with the “day” term, is that this phase will likely take more time than the previous ones. After all, you are finally translating your discussions, visions and plans into a real product.
At the end of this stage, you should have a fairly finished version of the final product or feature. Make sure that you remain aligned all the way through this process, but that you stay open to improvisation. You cannot predict the unpredictable!
And Day 5 is the day of judgement. This is where users (either internal or external stakeholders) must be brought in to test the product. Make sure that there has been a work of promoting and preparing for this launch. Is the release directed at a select group; or to the whole public? What is determining your decision.
You need to be very careful at this stage, because people have devoted substantial time to these efforts. They might be sensitive or stressed in the final stages, and you must be receptive to sudden concerns. Also, make sure that your customer-oriented teams have been aware of the development process, are aligned with the product vision and are ready to share it with the wider public.
Of course, we could add a Day 6. This is where you collect all the data, analyse mistakes, celebrate successes and try to understand where you could improve in the next spring. While some offices are really hierarchical and prefer to restrict this information to senior members, it might be worthwhile to even hold a short meeting. This open format will ensure that all teams understand what they did and how they could do a better job next time.
Product Management Design Sprints: Doing A Lot for Less
If there is something added by a Product Manager, that is value. It is all about efficiency; their ability to work across departments and juggle disciplines multiplies team efforts. Indeed, their efforts should also be guided a desire to cut costs, saving time and adding flexibility to operations. Design Sprints exemplify this work to perfection, as their short-term but intense nature bring to light the “guerrilla-style” work that has made some Silicon Valley companies leaders in their sectors.
While every background will contribute a different flavor to this practice, most PMs launching a Sprint will face these essential realities. Remember to work for alignment, stay transparent, share feedback and preserve the original product vision.
How do you face Product Management Design Sprints? Let us know below!
This article was originally published on The Product School blog.
We teach product management, data analytics and coding courses in 16 campuses across the US, UK and Canada and the world. To learn more about our upcoming courses and how to apply, visit our course page.
Have any comments? Tweet us @ProductSchool!
