Product management can be a strange beast. On one hand, you work your butt off to get your team motivated, aligned, and focus on building the right product for your users and shipping them on time. On the other hand, it is also your job to unify executives from other teams and keep them on track in the right direction.
If you’re anything like me, you’ll probably attempt to achieve this by inventing some form of process for everyone to follow. In this series, I hope to share our successes and failures when it comes to designing and executing the product management processes at Saleswhale.
Design Sprint process at Saleswhale
At Saleswhale, we’re a big fan of the Google Design Sprint methodology. We have used the process to launch several impactful features in the last 2 years.
I was introduced to the Design Sprint methodology during my first job at Google. As part of my 20% project, I led the Design Sprint facilitation for all the new Googlers (or Nooglers) for a full day. All Nooglers were asked to choose a problem they care about, interviewed actual users in the building, and came up with a solution prototype in 1 day. It was a really fun exercise to build a design mindset for new employees and bring people together.
When I joined the Saleswhale product team, we continued to use Google Design Sprint for new product development. Instead of someone handing over the requirements to our designers and engineers, we bring users and stakeholders together in the same room with the product builder so they could design the product together.
We've shipped impactful products after each Design Sprint. Our team members repeatedly shared with us that they enjoyed the sprint experience, even when we migrated to the remote way of doing it. They asked great questions, designed thoughtful workflows, and often came up with edge cases even before user testing.
After 2 years of what I assumed were effective ways of working, my CEO, Gab started poking holes in multiple product team processes. Every Tuesday at the Providore, he and I would have long chats about the product and the future of our company.
We’re both painfully direct and opinionated. Our conversations, as such, often get heated as we push to challenge each other to get better. I remember how he challenged me hard on the Design Sprint process at Saleswhale.
Gab: “What’s your view on taking away Design Sprint? I don’t see any innovative ideas coming directly from the process.
Why can’t you and I sit down with our designer to sketch out a prototype, iterate it with users and hand it over to engineers to implement? Wouldn’t it save us time and engineers can do what they do best - coding?
During offboarding, some engineers told me they see Design Sprints as a waste of time. They didn’t like to sit in the room, listen to some soft stories from business users and sketch out an idea that will be thrown away at the end anyways. Thoughts?”
I was taken aback by his question. I always have thought we ran the Design Sprints pretty well.
I was feeling somewhat defensive and thinking to myself:
“Does Gab want to take complete control of product development? Is that the underlying motivation? Is he one of those B2B founders that often want a top-down, waterfall approach?
Is this what's happening here?
Should I start job searching again so I won’t have to become a glorified project manager?”
I took a deep breath and asked Gab:
Thu: “You’ve participated in some of our design sprints before.
What do you think are the main goals of doing a design sprint?
Where do you see us meet or fall short when it comes to those goals?”
Gab: I’ve sat in all the design sprints, and it seems like the design sprint is doing a great job to align everyone on the same problem space.
The final ideas for the prototype though seem to be derivative. We always have to rework them after the Sprints anyways.
Look - I think this is the difference between B2C products and B2B products.
In B2C, engineers and designers could be the end users. They could come up with their own product ideas and won’t rely as much on the product managers.
In B2B, engineers are not the users, and hence have to rely on the PM to understand the customer. The PM has to drive more. I want to see you drive more. Right now it just seems too consensus-driven.
B2B PMs need to be well steeped in customer research, empathy, and market/comp analysis. They need to have conviction. The gap between PMs and engineers is much wider here compared to B2C.
I smiled and realized the problem here.
Gab was expecting us to come up with a groundbreaking, well-thought-out product from the Design Sprint alone.
In reality, our goal to run a design sprint is to drive alignment for the team on the problem space, bring engineers and designers closer to user pain points, and give everyone a chance to pitch any crazy ideas that could solve the problem.
The MVP from the design sprint is often embarrassing. We usually need to redesign them significantly after user testing. The end product might look very different from what we came up with during the design sprint.
It's a very uncomfortable experience for some people as they will need to throw out their beloved creative ideas.
I was ready to push back on Gab, and share my thoughts with him on the long-term and second-order return from this process, and why we should continue doing it.
First, the design sprint motivates product builders to care.
Our product team spent significant time sharing customer interviews and inviting sales and customer success to designers and engineers. Instead of claiming we’re the voice of users and forcing a feature on the team, we create an environment for engineers and designers to understand our customers deeply from all aspects.
This often saves the product team plenty of time going back and forth to explain a workflow, edge cases, and problem space for the design.
Second, the design sprint brings democracy to the product development team.
Everyone can pitch ideas that could solve the problem for our users. To paraphrase the chef rat in Ratatouille - everyone can build a product.
Our product managers don't have to pretend they are Steve Jobs and try to be right all the time.
I know some PMs / founders like to be Steve Jobs, but let’s face it - it’s harder to scale when all decisions and product ideas are centralized from 1 person. Yes, democracy brings chaos but chaos often begets unexpected innovation.
Third, the design sprint helps us to combat perfectionism.
In our early days, I often observed the team tend to spend a lot of time gathering inputs from everyone to build the perfect plan. There was a time we wrote way too many product memos, answered back and forth 100+ comments from everyone, and in the end, shipped nothing.
This is the byproduct of one of our cultural values: Rigor. We hired really smart people who love to debate. The downside of rigorous conversation though is perfectionism.
With the design sprint, we shipped prototypes to get user feedback in one week. When the feedback is validated, we start to scope down the works and get the first usable product in 6-12 weeks.
Sure, we did ship products that failed to get traction and had to retire them. Looking back though, we learned ways more by shipping than debating on Google docs.
And I constantly remind the team that even at FAANGs, 95% of experiments don’t work out. The team that wins is the team that understands the problem space so well and ships regularly.
This doesn’t mean that Design Sprint is a perfect tool to come up with great product ideas at any time. I have seen teams fail to get outputs from the design sprints.
Design sprint, in the end, is not a magic pill to solve growth issues. As with any tool, it’s up to the toolbox owner to deploy the right tool to the right problem. The design sprint is a tool and should be selected mindfully for the right problem and right team.
From my experiences, you shouldn’t use Design Sprint when these 2 conditions happen.
Problem scoping is not finalized
When problem framing is not done well, design sprint conversations can go in any direction. The product team often faces the dilemma when we try to bring engineers and designers to the problem space. We could either end up:
At Saleswhale, we reserve a full day just for problem discussion.
Product managers will do the heavy work of preparing the 1-pager brief, supply the relevant data points, and prepare a scope suggestion before the design sprint to frame. They become the reading homework for design sprint participants.
I don’t think there’s a specific solution to this scoping and framing user problem. It’s an art and requires deep product sense and regular trial-and-error.
The biggest mistake I saw people make with Design Sprint though is to skip this process altogether, hoping by going through Design Sprint, the team will be able to prioritize the right problem and scope it down elegantly.
Engineer-product team fit: System engineers vs Product engineers
Gab has a point on engineer feedback for our design sprint.
Looking back, I realize some engineers don’t exactly like to build user-facing features, especially if the users are in business functions (in our case marketing and sales team). They’re more motivated by the challenges of optimizing tools or building distributed systems.
Design sprint meetings can become exhaustive for those engineers.
Their feedback on the design sprint, though not positive, helped us to rethink and revamp our hiring and team match process as well.
After series A in 2019, we doubled our engineer headcount to prepare for scaling.
However, when we start to understand more about our growth channel, we realize we need to fix the core gaps in our product to support our go-to-market team and product-led growth motion to acquire leads.
We had to ask some of our system engineers to join the product squad and de-prioritize system work despite their interest. We learned the hard lesson now to come up with a clear growth plan for a product, identify whether we need to hire product engineers or system engineers and make sure engineers’ interests match with how the squad works.
Summary
I was glad that Gab challenged our product team to reexamine our design sprint process.
In the end, we both agreed and decided to keep our design sprint process after making a few adjustments. And it has worked out very well so far.
We also come up with a simpler process when we want to experiment and validate risky ideas quickly (I’ll share this in our next blog post).
For hiring, we are writing a new JD for a product engineer position to highlight our design process and the need to be user-focus.
Ultimately, we want candidates who care about having an impact beyond just code editing and are passionate about finding ways to shape our product as well as our product development culture.
If you’re interested in making an impact as a product engineer, product manager, or product designer at Saleswhale, we’d love to talk to you. Send us a message on the intercom!
Head of Product at Saleswhale
How design and engineering work together to solve problems for users at Saleswhale
18 NOV 2021
James Keys, Saleswhale's backend engineer and agile coach, shares about our unique approach to agile delivery and how it benefitted us.
3 MAY 2021
At Saleswhale, our interns do work that adds value to our company and customers. Read more about what Saleswhale internships are like.
7 AUG 2019
This is the beginning of Saleswhale and 6sense coming together, joining forces to create something really unique. This is a chance to upend the entire sales...
20 JAN 2022
