At Signifyd, the Product team comprises Product Management, Product Design and Product Experience. We set our goals high as a team. Our mission is to define the future of fearless commerce by designing products that solve pain points and create new innovations for our customers. Most importantly, we are a customer-driven organization, continuously validating and testing product ideas and improvements with our end users.
In this blog post, Mariana Ortiz-Reyes our director of product design and experience will share some thoughts on using the design sprints methodology to tackle big-hairy-scary opportunities from the product roadmap.
A product roadmap as a collection of inputs
Anyone in Product can tell you that their roadmap gets influenced by a multitude of ideas, suggestions, customer needs and feedback. At times, the input comes in like a flash flood, making a product leader feel on unstable ground. By contrast, in the best scenarios, a product leader is out and about nurturing many partnerships, especially those with their customers as well as with others in the company to inform and execute on the roadmap proactively — here the product leader might feel like a champ escalating to the top.
When a product leader is planning and executing a roadmap, they have to reconcile the input coming from the expected sources — customers and company executives, for instance. And they have to consider other variables, like competitive pressure and sales cycles.
These inputs are often in the form of ideas that need to be expanded and validated before moving to the build phase. Sometimes a product leader will have to confront a two-fold challenge which frequently seems insurmountable: first seizing the opportunity and pushing to explore these new ideas before the pressure to execute settles in, and secondly the less-than gratifying task of managing expectations and communicating with those who are offering input — especially when these fall at the bottom of the priority list.
Mo inputs, mo problems?
At Signifyd we are no strangers to the multitude of inputs, needs, desires and business opportunities that impact our roadmaps. Some recent examples of inputs to our roadmaps that provoke a need to seize the opportunity include (1) technical constraints that made our order review experience’s dated technology difficult to write and update, and (2) the desire to future-proof the policy management experience. Even though these examples have a scope and a sense of urgency, there is nothing like a fast-moving startup to sway a Product team away from prioritizing some inputs over others.
Moreover, it might be the case that as product leaders or as leaders in any function, we hesitate to tackle big-hairy-scary challenges either because we feel alone owning such a task, or because there seem to be multiple starting points to a project with such a large scope, or because the business implications are so vast we simply get paralyzed. This can happen to an individual or an entire team.
Looking back on our typical product development process at Signifyd, we’ve had our share of successful projects that prioritized longer discovery phases before committing to build, while other projects, relying on quicker, hunch-based execution, stand out for having. been built and launched before we knew for sure what would be the best approach. Typical product development processes make us think of some opportunities: How might we accelerate decision-making? How might we reduce risk in strategic projects? How might we learn faster without building or releasing?
Product discovery and design sprints in our practice
In defining our best practices as a team, we look for inspiration from new and old schools of doing. Tim Herbig encourages us to look at product discovery as a “combination of activities to navigate the problem space.” Ultimately the goal is to determine what should be built using a process that will give us confidence and reduce uncertainty. The activities we do during product discovery are meant to keep us focused on prioritizing, defining and understanding the problem before jumping into the solution.
We believe that as a customer- and user-focused team, we aim to be constantly engaged in some discovery process — this is because we prioritize understanding customer satisfaction, collecting user feedback and engaging in means to acquire insights about the market.
One methodology in our current toolkit that has allowed us to pursue the exploration of strategic inputs in a speedy manner is design sprints. As defined by its creators, Google Ventures, design sprints are a short, time-boxed process for “answering critical business questions through design, prototyping and testing ideas with customers.” And in contrast to the typical product development process, it “gives teams a shortcut to learning without building and launching.”
A design sprint, different from an agile or scrum sprint which our teams use in the lifecycle of an existing product area, is best suited to address a challenge that requires cross-functional design thinking and is of critical business value.
So far we’ve completed two design sprints at Signifyd, we have one more scheduled and an aspirational goal of executing at least two a year. The two sprints addressed very different goals for two different experiences in our product ecosystem. However, in order to make decisions in each one of these sprints we made sure our participants represented the voice of the users, the business, the technology and our stakeholders.
1. Explore the limits
With the inevitable architecture upgrade of our order review experience and our flagship user interface, the team needed to question the possibilities and constraints of an upgraded user experience.
Out with the old, in with the new? Not exactly. In collaboration with our stakeholders we determined that anything newly built needed to comply with the following:
- Competitive, market savvy and distinct advantage
- Like the old, but better
- Flexibility of adoption
- Early communication and open feedback collection
- Gracefully adapt and mitigate inevitable change
Our first design sprint helped us set aside fears and hesitation to kick off this inevitable upgrade — Scary!
The design sprint resulted in a concept that moved us in a distinct and new direction: Remove the separation between the order traffic overview capability, the orders search results and the order detailed view — capabilities which hold the key moments of value for the user personas targeted in this exercise.
The decision to pursue this new direction towards a seamless order review experience would have been very different without dedicated time for technical exploration paired with the early validation during the design sprint. Fast forward to the end of the sprint and everyone back at home base, continuing to work with engineering in early feasibility allowed us to put in perspective the impact of the concept on the search backend and the desirability of the changes within the roadmap. Hitting limits is not all bad. In this case the concept needed to be broken down further in order to execute.
With the intent of moving forward from an MVP of the policy management experience, whilst still addressing prioritized roadmap work, the first question to tackle when deciding to execute this design sprint was: Why think about what’s next now?
Two things were clear to us: Policy management capabilities have been around for some time and the users’ wish list was only growing.
The remote design sprint was scheduled with the following mindset and reframed urgency: It’s time to take a look at the whole user journey of policy management to identify and ideate for needs beyond current user requests, if we want to build platform services that serve users’ longer-term policy management tasks.
Our second design sprint helped us think ahead while managing the pressure to fight fires — Hairy!
Design sprint outcomes
Design sprints typically form part of a bigger project plan that is set in motion to tackle big-hairy-scary strategic input.
After completing our design sprints we were happy to have learned and tested a product direction. But that’s not the end-all. Ultimately our teams needed to inform the product roadmap and decide the next steps accordingly.
Impact to the roadmap
Getting from idea to implementation is a core problem inherent in the job of a product manager or product designer. When managing input into a beating roadmap (Yeah, I think the heart of a product is its roadmap — more on that another time.), there’s plenty of negotiated priority that corresponds to factors such as an impending customer deal, development velocity and others. For us, the outcome of our design sprints are meant to put in perspective the multitude of inputs by confirming urgency or validating need so that the product leader can better make decisions on how to proceed with planning.
Design sprints might be a household methodology for many in tech, a new practice for others and a world to discover for another few. The participants in Signifyd’s first design sprint were hesitant. Thankfully, in my experience, our stakeholders were less hesitant. As the planner, facilitator and designer of our first sprint, I had my own doubts. But the guidance out there from Google Venture, the book “Sprint” and many others who dedicate time to write, blog and produce videos about it, make it clear and repeatable. Shout out to them for their unknowing assistance and to my teammates for embarking on new learnings together.
Our first sprint turned out to be the last opportunity for a long time to get together in person for such a critical and new activity — calendars blocked and nowhere to go for five days. (We flew folks across the world for it.) Now our almost exclusively remote interactions make things a little different for engaging and getting time commitments from participants and stakeholders. But a virtual design sprint is hardly impossible.
A few things that helped us manage our online design sprint included:
- Choosing a flexible and learnable online platform. Our team has access to FigJam and LucidSpark as collaboration canvases. These are priceless tools where everyone can work together in real time. When we’re hoping for a quick jump into design files we use the first. And when we intend to spend more time diagramming and moving virtual post-its within ideation and synthesis frameworks, we use the second.
- Offering multiple ways to connect over an active Zoom, a dedicated Slack channel and the online canvas. People will need to jump in and out of the conversation but that does not mean the collaboration has to end. It was important to be flexible and have the tools open for people to add thoughts at odd times.
- Documenting instructions and guidance each step of the way prior and during. Unlike in-person interaction where you’re reading body language and having clarifying one-to-one communication to unblock a process, online we can quickly lose the audience to distractions and doubts about the process. Having the documentation handy so that people can go at their own pace was important to get all the input necessary.
In the end, adapting the methodology for our purpose and making it repeatable in our context at Signifyd makes design sprints a best practice for us.
And finally, feedback like this from my engineering counterpart Geoff Miller makes introducing a new methodology to my team all worth it: “Shout out to Mariana for her planning, executing and delivering, in my eyes, a very successful design sprint last week in Belfast. I was skeptical of the amount of structure and meeting time required but that faded as each day went on. I thought it was an excellent use of all of us who were in Belfast from the U.S.”
Are you a champion of expanding Product’s toolkits? Are you curious and hungry? Fancy rolling up your sleeves with us? We are collaborative and highly cross-functional, bringing everyone together to get the job done. And we are actively hiring product designers and product managers.