Use Design Sprints to Improve Your Product
Problem
We were building a completely new product in the energy utility space. Essentially, the team was building websites for utilities; those websites were the places where you could sign in for a service, pay a bill, or set a recurring payment. All of that required Oracle back-end and though we were acquired by Oracle none of us was familiar with that domain. At the peak, we had around 35 engineers, five PMs, and a DevOps team with zero domain product context. As a consequence, our planning and delivery were very haphazard and indeterministic.
Actions taken
To solve the problem we tried a number of things from training to reorganization, but one thing more than anything else contributed to our good results.
We made a concerted effort to use design sprints when working across product, UX and engineering and use them a quarter in advance. For example, if we were to build a view your bill feature we would think through in advance what that would look like from a product, UX, and engineering perspective. While that seemed fairly straightforward, getting into a habit of doing design sprints and expanding that habit to the whole organization didn’t happen overnight and required a continual effort.
To do that we, as a leadership:
- Introduced the concept and kept talking about it all the time. It takes on average seven times to repeat something for a person, team to comprehend it.
- Piloted with teams to work on design sprints. I had five managers reporting to me and whichever team would have the flexibility to take a week off and focus on a design sprint, would take a lead on that.
- Applied the teams’ lessons learned and successes and had managers further share the knowledge out.
The reason we decided to try design sprints in the first place was that my product counterpart of that time, read and was hugely inspired by the book The Design Sprint by Jake Knapp. Though I haven’t read it then, I intuitively knew that we were missing the knowledge and context that would allow us to plan our work better. You could call it whatever you want, but I knew that we need to take time off and do research. However, I never wanted us to do it in a Big Bang fashion and for months be buried in research. We were trying a number of things, some even Waterfallish in its essence. We had an engineer take a stock of all the APIs that existed and catalog it so that anyone doing the design sprint or research spike was able to quickly reference that.
One of the things that encouraged us to seek a different approach was that in the past we were constantly failing to hit our targets because we were unable to anticipate the complexity and/or the dependencies of a project. For example, we would decide on building a view your bill feature, but we didn’t know what it would take to build it.
Lessons learned
- Oftentimes you will approach a project without not the slightest idea what you should be doing. Prepare to fail but to keep on doing what you think is right. Retrospectives are crucial to inspect your work and come up with a plan for improvements, and not only on a Scrum sprint level but on the macro -- director or manager of managers -- level. That is something we don’t do enough. You are frequently working on multiple things at once and that makes retrospectives complicated, but nevertheless can help you identify gaps and issues you didn’t know existed.
- Don’t skip pre-mortems. They should help you identify all things that could go wrong. We also did it in this particular case but didn’t project long enough into the future. If we had only though two steps further we would have come up with the concept of the design spring by ourselves.
- During all those meetings, be open and be vulnerable so that all your biases are suspended. Don’t be defensive, you are all in the same boat.
Be notified about next articles from Ghanashyam Prabhakar
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.