I don’t know about you, but I cringe at the thought of having to commute. The traffic, road rage, not to mention having to find parking… it was enough to make me throw in the towel 7 years ago!
Since then I have been managing remote teams around the world, and as I continue to scale my team I learn best practices from companies who have been doing it for longer than I have like Olark.
But, I know there are a lot of people out there who just don’t know if they can do it.
Maybe you’re one of them. You worry if you’ll be productive, able to communicate effectively and fit into the company culture.
One of my employees, Meghan Burgain felt the same way about a year ago. She had a number of reservations having never worked remotely before.
In today’s Build episode, Meghan and I are going to dive into some of these reservations, how you can get over them, and of course the wonderful benefits aside from working in your jammies ;)
You’ll learn:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Transcript for Remote Working: How To Succeed In Your First Remote Working Position
Poornima Vijayashanker: Hey, guys. I'm hanging out here in beautiful Bordeaux, France, and taking you behind the scenes this week to show you what remote working is like at Femgineer. If you've been on the fence about taking a remote position, stay tuned for a number of tips in today's *Build* episode.
Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. For the past seven years, I have been managing remote teams around the world for my startup as well as other companies. Today, I'm joined by Meghan Burgain, who is the mother of twins and expat who lives here in Bordeaux, France, and is Femgineer's community manager. For the last year, Meghan has been working remotely and she's going to share some of her favorite tips to help you get over any reservations that you might have when it comes to taking on a remote position. Thanks for joining us, Meghan.
Meghan Burgain: Thanks for being in France, Poornima.
Remote Working Reservations
Poornima Vijayashanker: I know a year ago when I approached you about remote working, you were on the fence. Let's talk about what some of your reservations were.
Meghan Burgain: Yeah. My education and a lot of my experiences are in education. I was actually a teacher before I moved here. I was a little concerned about getting up to speed, getting trained at Femgineer. That was one of my concerns was getting trained.
The other one of course was that Bordeaux is nine hours ahead of San Francisco. I knew that there was going to be some difficulty there. Would I have to stay awake at night to get all of the work done or not? Those are my two concerns.
How To Handle Time Zones When Remote Working
Poornima Vijayashanker: While you got over the hurdle and joined the team, I know there was that first hiccup that you had where you missed a meeting due to the time zone. What did you learn from that experience?
Meghan Burgain: Time zones are really tricky. I learned that basically communication is paramount, especially when you're working remotely. You need to be explicit, very clear, search for the clarification, ask the questions that you need and really just be polite when you're dealing with people through email. With chat, it can be difficult to maybe misread something so just to be polite and that avoids 90% of the issues.
Poornima Vijayashanker: Then you eventually got over that and learned a number of things over the last year. Let's start with the first thing that you learned.
Recommended Tools And Processes To Stay Productive As A Remote Worker
Meghan Burgain: Right. The first thing I learned basically was the importance of the tools that we use. Being that we're not in proximity, we use the tools like Trello and Slack. Trello is great because obviously for communication you can see who's doing what, if it's done or not, but also allows for transparency. You can see the bigger picture: what we're focusing on at Femgineer, what the priorities are, and how that should affect how I prioritize my own tasks as well.
Poornima Vijayashanker: Now, I know another thing you've learned that is even though we're a remote team we still do weekly check-ins where we sync up. Walk us through how weekly check-ins have benefited you.
Meghan Burgain: Weekly check-ins are really important. In startup plans, especially, products change, priorities change, and the weekly check-ins really help me, us both I feel, to stay focused and to stay in the same page working towards the same goal.
Training New Remote Hires
Poornima Vijayashanker: Now, I know the third thing is that you were concerned about training, getting trained, training other people. I know as we've scaled the team, you had to train others. How have you gotten over that hurdle?
Meghan Burgain: It's funny that that was one of my reservations and that's actually something that I've been doing at Femgineer. Well, I've realized that training someone via Zoom or Slack, it's not that much different than training someone in person and, in some cases, can actually be better because we can record the training and use it in the future which is what we've done a lot. I've also been relying a lot on our handbook.
Poornima Vijayashanker: What's our handbook?
Meghan Burgain: Our handbook is basically a recipe book for anything that's recurring at Femgineer so whether it's daily or just a certain time of the year, if it happens more than once, it's in the handbook. It's outlined. There's helpful tips and there are links to any outside resources that we might need.
Remote Working Benefits
Poornima Vijayashanker: Great. Walk us through what a typical day is like for you.
Meghan Burgain: A typical day I wake up. We get the girls ready. Send them off to daycare. Then I have the majority my day to do the daily tasks that I need to get done, answer emails that came through to do all of my tasks. Towards the end of the day, when the States wakes up, I'm able to schedule phone calls, have meetings and that sort of thing. It's where I base the first part of my day, I didn't have any of those interruptions. I was able to just do whatever I wanted at my own pace. At the end of the day, I have all the things that I need to interact with people. Then I do my to-do list for the next day and it's off to get the kids.
Poornima Vijayashanker: Nice. It sounds like you have a lot of flexible hours.
Meghan Burgain: Oh, yeah. Well, for sure. I have deadlines just like anyone else, but I do have a lot more flexibility with how I get those things done.
Poornima Vijayashanker: What do you think are the key benefits that you've experienced by remote working?
Meghan Burgain: You mean besides being able to work anywhere in the world and in my own kitchen and in my own sweatpants?
Poornima Vijayashanker: Yes. Those are great benefits, by the way.
Meghan Burgain: I would say that the biggest benefit of working remotely is that I've really been able to find a work-life balance that works well for me. I'm able to not only be there for my kids and my family but to provide for them as well. I think that that's just an invaluable thing. It's a win-win.
Remote Company Culture
Poornima Vijayashanker: I know for some folks out there they might be on the fence about remote working because of the culture. They might feel like, oh, it's isolated or distant. How have you managed to manage that?
Meghan Burgain: I could see how it could be lonely. You don't have someone just next to you to talk to or whatever but I haven't felt that way and I think to go back to the weekly check-ins, that that's really one of the reasons is that we do get that face time. Also we have Slack which we can talk to all of our team members. I would say when it comes to the culture and the team feeling, you get what you give. It can be tempting in any working relationships, especially in remote working, whenever you find someone that's available within your timezone to just ping them with the 20 questions that you have or to ask a hundred things of them. But, I would suggest to all of you that the first thing that you do to someone should really be to ask them how they're doing, to find out what their interests are. It goes a long way towards creating the spirit and creating a team.
Poornima Vijayashanker: Building a rapport maybe through a water cooler channel on Slack.
Meghan Burgain: Yes. Yes. That's what we have.
Poornima Vijayashanker: Wonderful. Well, thank you, Meghan. This has been really helpful. I know our audience out there is going to benefit from these tips.
Meghan Burgain: It's been my pleasure.
Poornima Vijayashanker: Wonderful. Well, that's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode where you'll get more helpful tips like this.
Meghan Burgain: Ciao for now.
Poornima Vijayashanker: Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
Hey, guys. I'm hanging out here in beautiful Bordeaux and I'll just start again. All right.
In today's Build episode, we're going to talk to you about ...
Meghan Burgain: Remote working.
Poornima Vijayashanker: Yeah, I know. I forgot what I should introduce you before I ... I think I do need to. OK. Take two.
Did you share last week’s Build episode on product design sprints with your teammates?
Wait! Give me two chances to guess what the outcome was...
… you did and you faced some pushback? Well, kudos to you for putting it out there!
… or maybe you didn’t because you were afraid of the pushback you’d get? That is OK too!
Charbel Semaan and I are back this week and prepared to help you get over the pushback you received or will receive once you bring up the idea of product design sprints to your teammates.
You’ll recall Charbel Semaan has been a product designer for the last 20 years and recently launched his brand, Made in Public.
Charbel and I have built a lot of products, and we know that even if our teammates hate the current process and the outcomes it produces, they will still find comfort in it and resist adopting a new one because there’s a lot of fear when it comes to change.
But no one is going to willingly admit to being scared, so they’re going to couch their fear in remarks that are skeptical, just say no, or create excuses like: “Now is not a good time.” “We just don’t have the money to run extra experiments.”
Then there’s my personal favorite: “Prove to me that this is going to work!” But the whole point of an experiment is to test assumptions by following a process, and then seeing if they were right or wrong. You can’t prove anything until you do the experiment! #chickenegg
Because we want you to be really prepared for all the excuses and pushback around a design sprint, here are a few more excuses that you’ll hear when it comes to product design sprints from our friends at Invision. There are also some guidelines and prerequisites that we recommend you consider mentioned in this post to make sure a product design sprint is right for your team.
By the time you finish watching today’s episode you will have learned how-to:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
Transcript: Product Design Sprints: How To Get People To Adopt Product Design Sprints
Poornima Vijayashanker: In the previous episode of *Build*, we shared how you can use design sprints to help you test ideas out faster and get that much-needed feedback. If you miss the episode, I've included a link to it below this video. And of course, anytime you want to institute a new process in your organization, there's going to be some pushback, so in today's *Build* episode, we're going to tackle how you can evangelize design sprints within your organization. So stay tuned.
Welcome to *Build*, brought to you by PivotalTracker. I'm your host Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Today we're continuing our conversation with Charbel Semaan, who has been a product designer for over 20 years, and most recently launched Made in Public.
How To Handle The Pushback When It Comes To Trying Out Product Design Sprints
OK, Charbel, you and I have built a lot of products, and we know that even if our teams hate our current process, and we give them a new one, they're still going to be reluctant to adopt that new one because there's that fear of change.
Charbel Semaan: Sure.
Poornima Vijayashanker: And we're going to get pushback. So how do we handle that pushback?
Product Design Sprints Aren’t Meant To Replace Existing Product Development Process
Charbel Semaan: I think one of the ways I found to handle it successfully is to emphasize it's not a replacement to your existing process. It's a way to supplement, complement, or augment. And if you can run a design sprint in parallel and you're really doing it as a side branch to what you're already doing, and it gives you an opportunity to learn quickly in five days, and then be able to integrate that back into your existing processes. It's super helpful.
Poornima Vijayashanker: OK. So that's great in theory. But I know having to run a parallel process oftentimes for either a small team or even in a large organization can be a lot of setup. It can mean trying to carve out that time, so one of the key things to consider is what are going to be the benefits. Someone's going to come and say why should we do this, how is it going to help?
The #1 Benefit of Product Design Sprints: Speed of Execution
Charbel Semaan: Great questions. Why should we do it, how is it going to help. I think there are two key areas. One is speed of execution.
Poornima Vijayashanker: OK.
Charbel Semaan: And what comes along with that, with the sprint, is constraints. And through those constraints you get clarity. So you're moving quickly, you're going from thinking to action in a quick way, and you're also constraining yourself so you don't have an infinite amount of time to decide what features, what angle, should we try it this way or that way, so you get to move quickly and you constrain yourself, so you get to clarity faster.
Poornima Vijayashanker: OK. So I'm sure for our audiences out there, there's probably going to be some pushback around, ah that's great on like a nimble team of maybe five, six people—but I've got 10, 20, 30 decision makers or stakeholders. I'm not going to be able to mobilize my team fast enough. So how do we get to handle those folks?
Can product design sprints work for larger teams?
Charbel Semaan: Yes. I think you can work with those 10 to 20, or even 30 people to understand what are some big problems that you're facing, that you'd want to solve, that are top priority, or they're really affecting and impacting your productivity and your flow, your ability to ship.
Poornima Vijayashanker: Even if they're conflicting?
Charbel Semaan: Even if they're conflicting. I think you first start by gaining an understanding. So with a team that large, I've got 20 to 30 product managers and squads of teams of PMs and developers and designers, etc. You gain an understanding, if you're that org leader, gain an understanding of what are some of the top big, immediate problems that are affecting the team and affecting shipping and product and affecting the business. And prioritize those. And then think about if I can run a sprint, if I could run something within five days and gain clarity and be able to unlock some blocker that's going on across those 10 to 20, then who of that large group, who would make most sense to bring into this sprint.
We're not going to stop the presses on everyone's workflow. But we can at least prioritize, run a sprint with some key players, see how that goes. In some ways it's a look at like an 80-20 perspective of 80% of the orgs, when you continue going as-is, there's going to be this 20% or even 90-10, there's going to be this small experiment we're going to run. And if that's successful, then we can see if we can apply it to other areas or aspects of the org, no matter how large.
Poornima Vijayashanker: Of course there's fragile egos. So some people are going to want to be in that special pool.
Charbel Semaan: Sure.
Poornima Vijayashanker: Why wasn't I picked?
Charbel Semaan: Sure.
Poornima Vijayashanker: So how do you message that?
How To Convey Who Does And Doesn’t Needs To Be Involved In A Product Design Sprint
Charbel Semaan: Not easily. Not easily. It's not always easy. I think one thing I've found a bit helpful is to communicate openly that we understand we have X-Y-Z challenges. We're all clear on that. And there's...hopefully you have consensus, you have agreement. And from there it's...we can't tackle them all at once. We all agree to that. And so I think you're gaining that consensus and that understanding. That mutual understanding. And then communicating, we want to try something that might help us start to chip away at the stack of challenges that we have. We're going to run small experiments. As those turn out to be successful and we learn from them, we want to continue embracing and permeating through more teams and more people in the org.
So it's coming and if it's going to work, they know it's coming, if you have a deep interest and you have a really...you're raising your hand and you really want to be a part of this, please come to tell me. If you're the org leader or the business leader, whoever you are. I think that kind of openness and communication starts to also be a signal for you to understand who are the people who, as you mentioned before, who are the people who can become those evangelists and those change agents in your organization as influencers to adopt something new like design sprints, and then be able to take it to their parts of the org as well.
Poornima Vijayashanker: I think it also serves as a signal to see how open your organization is, right?
Charbel Semaan: Absolutely, absolutely.
Poornima Vijayashanker: So I think maybe some people may get disheartened as they do this exercise and find out that they're not getting a lot of interest, so how should they take that? It's not a reason to send in your resignation letter.
Charbel Semaan: No, no, not at all. Don't do that yet. I think one thing though, is just discussing with a CO of a global manufacturing business, is people need to feel involved. In my experience, in org development and innovation with an organization, especially large ones that no one really wants to have something just told at them, and that this is the way we're doing things now. So introducing something like a design sprint into your organization, that can foster and cultivate innovation throughout all your people. Doing so by involving them.
So first it just starts with communicating that. We're thinking of doing something new. Who has some initial interest? They're like you said, you'll start to see if there is or isn't. That might be an indicator that are you really getting that kind of engagement from your folks, and as you test and as you do small experiments and you see who continues to raise their hand and want to be more and more involved. And when you're not seeing that engagement, it may actually be an opportunity to run a design sprint on internal communications.
Poornima Vijayashanker: OK, yeah.
Charbel Semaan: So that's the beauty of it for me is, I think you can sprint on any kind of challenge you have.
Poornima Vijayashanker: Right.
Charbel Semaan: It may not always be a business challenge in the product sense, or in the service sense. Sometimes it may be about your internal organization.
Poornima Vijayashanker: And what happens if you get too much interest? Everyone's like, “Oh yes, I want to participate,” and all of a sudden you've got your 5,000-person organization and it's like, “I've got things to say. I see things that are broken.” Yeah, I get this a lot when I go into places.
Charbel Semaan: Sure, sure. I think for starters, I think that's a great problem to have. I think you want that level of engagement, that employee engagement, and your people care about solving challenges in your business. It's far better than the opposite. Two, there is such a thing called mega sprints, and Jake Knapp actually runs mega sprints, which were pretty interesting, where there's simultaneous sprints happening in one large room.
Short of that, the—to your point about the question is to get to a place where there's an opportunity for people to raise their hand, have a voice, to be able to add to the mix and add say, “Here's the challenge I'm facing,” and then it's really, I think, an opportunity to create a culture of that mindset. So I go back to design sprints not just being this rigid five-day process, and the irony is it's...it can be viewed as some rigid five-day process even though it's a sprint, it's meant to move quickly. The reality for me is that when you embrace it as a mindset, and that people in your organization, no matter if you have 5,000 people with 1,000 problems each, it's an opportunity to think, “How could I solve this problem or test a new idea quickly, and can I use the framework of the sprint, can I use the elements of the sprint to take action faster?”
And I think anybody who's leading an organization, no matter how small or large, would love for their people to have that type of empowerment and to be able to feel enabled and equipped to take action.
How Product Design Sprints Different From The Lean Startup Methodologies And Agile
Poornima Vijayashanker: Now there's also a lot of skeptics out there who might say, “Yeah, you know, I hear what Charbel's saying but I've tried something like this a year ago, or like five years ago we tried lean or agile—how do I know that this is the new thing?” So a lot of times the concern is how is this going to be any different from what we tried in the past that failed miserably, and in the wake of it, caused a lot of destruction.
Charbel Semaan: Yes. Great question. This has actually been coming up recently for me and I've been doing more and more review and research on this. I think for starters it's valid. It's absolutely valid to be wondering, “Great, this is just the methodology du jour. This is now the new thing, and everyone's going to jump on this bandwagon.” I completely understand that.
Product Design Sprints Are All About Constraints And Speed Of Execution
What I come back to though is the corner about the mindset. Lean can be thought of as a mindset. Agile can be thought of as a mindset. It's a way to knock down blockers that otherwise impede you from trying something, learning from it, and iterating on it. So whether it's this model, that model, or this or the other. I think the nice thing about sprints is that for me as a designer, because it's rooted in design thinking, and it provides this construct to float through five days—and again I mentioned clarity through constraints and that speed of execution—it gives you an opportunity to go from empathy all the way to testing the idea. And prototyping is of course in there, inside of that.
Whereas lean is focused on build, measure, learn. So you just start out by building and you're going to put it out and then learn from the reactions. As a designer I am a big believer in that initial upfront step of empathizing and understanding. When you understand what that problem is and who you're solving it for, and it carries you through that initial slice of the prototype that's just enough to get in front of users, and I have a hard time imagining folks who wouldn't want to move faster and learn more, and be able to then iterate.
And this is one way of doing it. It's a methodology that I've embraced that I...it gets me out of my own decision deadlock as well.
Poornima Vijayashanker: Yeah. So in the wake of that kind of feedback around, “Hey, how is this going to be any different, you're saying treat it as a mindset,” hopefully people are willing to adopt a new mindset or at least test it out. But there are also those who start to get kind of nitty gritty, right? They might say something like, “Oh, I don't even know where to get customers to test this prototype,” or, “I don't want to bother our existing customers.” How do you get over some of those more practical hurdles?
Charbel Semaan: Sure. That's a great question. On the customer front, I think, on one hand, you hopefully have a pocket of customers who have a major interest in everything you're doing. They want to be those early adopters. They want to test new features. They're your biggest fans. And so on one front you can always start with them and then treat them right, treat them in a way where you have this open communication that we appreciate coming to you because you're such a fan of ours and we're a fan of you, and we want to come bring you our latest and greatest to see are we doing right by you. Are we solving the problems that you need solved, are we getting the jobs done that you need done through our software or through our product or service?
So I think on that front you build those ongoing and sustainable relationships with them.
Poornima Vijayashanker: And if it's a new customer base?
Charbel Semaan: If it's a new customer base, I think going back to that understanding the problem and understanding who. When you understand those two things, it's surprisingly simple to find where they are. If you understand their habits, you understand their desires and their pains and their struggles, you understand where they seek the solution to this problem elsewhere, you can go to those places.
Poornima Vijayashanker: So do you have an example of a situation where a lot of these practicalities started to add up and people just completely lost sight of making a decision on design sprints?
Case Study of A Product Design Sprint
Charbel Semaan: Yeah. Great question. There's an example where...come back to the internal learning development team at Medallia. We had big needs, we had problems to solve in terms of scaling, training, especially for the growing sales team, the growing engineering team, which are very common teams that start to spark and grow quickly. And especially globally. So how do we scale the training? And practicalities like, well, video's going to be expensive. Getting all the equipment. Having the studio. Do we even have time to shoot video and do that. People don't watch online learnings. A lot of the common...what might be common sense or these truths that we think we have in our businesses, and the reality was when we ran a sprint, it was actually a colleague of mine and we ran a sprint.
Poornima Vijayashanker: So how did you get over that hurdle to actually get them to run the sprint given these practicalities?
Charbel Semaan: That's a good question. There were a couple of people who were advocates. They wanted to embrace it.
Poornima Vijayashanker: OK.
Charbel Semaan: And the challenge was showing that running the sprint and the output of the sprint...the output of the sprint was actually more important than the sprint itself in a way. So because the output...and first they wanted to embrace the approach. They embraced the approach. They wanted to try it. And they wanted to get to that output. So we shared that video with the entire HR organization, and the output, the video itself, was what people focused on. Then when they wondered, “Well wait a minute, when did you do this and how did you do it so quickly?” That's when we were able to say, “Well, we ran a sprint on it.”
Poornima Vijayashanker: Interesting.
Charbel Semaan: And we just shortcut a lot of the decision deadlock, a lot of the concerns and a lot...we did it with an iPhone on a makeshift tripod in this corner office that we blacked out the windows and we were able to just run with it. And it's not the greatest-looking video but it's a prototype. Then people realized, “Wow, we can go this quickly and this nimbly, why don't we embrace this and actually try to do more?”
And the greatest part about that—I love the outcome here—is that, the head of the team said, “Great. Here's a budget to go get the equipment you need, on a reasonable amount of money, and why don't we use this corner room more frequently for these videos and let's run with this.”
If All Else Fails: Show People The Output of The Product Design Sprint
Poornima Vijayashanker: So that's pretty cool. You basically turned design thinking on its head. Instead of trying to get people to adopt the methodology, just show them the output, tell them about the outcomes, and then when there's a curiosity for how did this all come about, then you can say, “We used design thinking.”
Charbel Semaan: That's right.
Poornima Vijayashanker: Cool. And I think then people are going to start to embrace it in more sections of the organization, or on more projects.
Charbel Semaan: That's right.
Poornima Vijayashanker: Well, that is an awesome insight, Charbel. So for those of you out there who are stuck, feeling a lot of pushback, maybe instead of trying to get people to adopt the methodology, present them with the output and the outcomes and use that to strike the conversation.
Thank you for joining us, Charbel, and for our audience out there, how can they get in touch with you?
Charbel Semaan: Great. Thanks for having me on. This has been blast. You can reach me at charbel@madeinpublic.com, and visit madeinpublic.com, and see the projects that I'm working on, the sprints that I run publicly to help teach and empower to run sprints themselves. And sign up for the newsletter as well.
Poornima Vijayashanker: That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more great episodes and short build tips. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.
How many times have you and your team spent countless hours building, bug fixing, finally releasing a new feature only to hear feedback from a customer that it’s not what they wanted?
Or worse, they don’t say anything…
Why?
Because they aren’t even using the new feature!
Back to the drawing board…
Yet again it again takes weeks or months to build and tweak and nothing changes. You just keep missing the target, asking for more time, money, and resources.
But it doesn’t help, and people just end up burning out building the wrong thing.
What if I told you that the problem in your product development process is that you are spending too much time, money, and resources and need to cut back?
OK, I’ll give you a minute to shake your head at me...
Sometimes when we have too much it causes us to go in a lot of different directions. Or worse no direction at all because we’re stuck in a decision deadlock!
We lose sight of our customers and end up building just for the sake of building, thinking that we know what problem we are solving, but we don’t.
As a result, our product debt keeps growing and a redesigns don’t help.
So how can we stop building the wrong thing and solving the wrong problem?
We can start by constraining the amount of time we have to help us focus on uncovering and solving one problem at a time.
And in today’s episode, we’re going to dive into the framework behind this new approach called product design sprints.
To help us out, I've invited Charbel Semaan, who has been a product designer for the last 20 years and recently launched his brand, Made in Public.
If you’re eager to get an idea out, worried about how long it’s going to take your team to execute, and concerned about wasting time, money and other resources, then you owe it to yourself to watch today’s episode!
Here’s what you’ll learn:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
## Product Design Sprint: How a Product Design Sprint Fast Tracks Testing Your Ideas Transcript
Poornima Vijayashanker: Eager to get an idea out there but worried about how long it's going to take you and your team to execute? Well, in today's *Build* episode, we're going to show you how you can embrace design sprints as a way to test your ideas and get your prototype out there faster. Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In each episode, innovators and I debunk a number of myths and misconceptions related to building products, companies, and your career in tech.
One misconception a lot of us fall prey to is this need to do a massive build out before we launch a product. The results, unfortunately, are that we end up spending a lot of time, money, and energy possibly building the wrong thing. As a result, customers don't want it, teams burn out, and companies lose sight of their business goals. In today's episode, we're going to tackle this misconception, share with you how you can embrace design sprints to help you iterate faster and get your prototypes out there, and in future episodes, we'll talk about how you can evangelize design sprints within your organization and handle any pushback that you might get from your teammates or stakeholders. To help us out, I've invited Charbel Semaan, who has been a product designer for the last 20 years and recently launched his brand, Made in Public. Thanks for joining us today, Charbel.
Charbel Semaan: Thanks for having me.
Poornima Vijayashanker: Yeah.
Charbel Semaan: I'm excited to be here.
Poornima Vijayashanker: Yeah. For our audiences out there, let's start by digging into your background a little. I know you've been a designer for the last 20 years and recently started Made in Public, but walk us through that evolution.
Charbel Semaan: Sure. I started out as a designer, self-taught, when I was 15 and fell in love with it. I continued to design through college, would dabble with side projects, and never formally studied it and was formally trained, but continued to develop my skills as much as I could. I've had this interesting blend of design specialties throughout my career. I've done product design, brand design. I've done curriculum design for training programs. Bringing all of that together, I've realized I've broadened my career or widened my career. What I enjoy most is using design as a way to solve problems as a methodology, and I also enjoy teaching it. I enjoy teaching designs so people can embrace it in whatever area of work they do.
Poornima Vijayashanker: Yeah, that's great. Now, what does Made in Public do?
Charbel Semaan: Made in Public now combines all of that and I get to run my own side-project design sprints. I run sprints publicly so people can see what it's like to go through the process of going from idea to action in a very short amount of time.
And then in that way, as well, I use it as a way to teach. I really like to teach design through live experiments.
Poornima Vijayashanker: Let's dive into today's topic of design sprints. Before we talk about what design sprints are, let's maybe start with that product design background that you have and showcase what you saw was broken and why the need, maybe, for a new process.
Why Do We Need A New Process For Designing Products
Charbel Semaan: Sure. I think part of it is...there may not always be something that's broken, per se. I think design thinking has influenced my career heavily, and I've learned a lot through what IDEO has put out into the world and other great design firms out there. I think design sprints, in some ways, is a derivative of design thinking. It's another way of thinking about the design process.
What it can help guard against or help avoid are things like decision deadlock. Or it helps guard against overthinking what the big thing should be and helps you pair down because of constraints. You have five steps, and according to the Google Ventures-inspired design sprint and Jake Knapp and the author, the co-authors, the five-day approach constrains you so you're not trying to build something that could take you five months.
Poornima Vijayashanker: Right.
Charbel Semaan: Really, you're trying to create something in five days.
What Does A Product Design Sprint Look Like
Poornima Vijayashanker: Let's talk about what that looks like. What is that design sprint over those five days?
Charbel Semaan: Sure. The first step of the five steps, or five days depending on if you want to compress it even further, the first step is to understand. Map and understand and unpack the problem you're trying to solve and for whom you're solving it.
I think for anybody who's creating any kind of product, it's always essential to get down to: what problem am I solving, and who has the problem?
Poornima Vijayashanker: Yeah.
Charbel Semaan: And do I understand that person and their journey and how they first might interact with my product all the way through to the interaction and to the end result, or what I like to call the desired outcome? What's the desired outcome that they want after using your product? What is it solving?
Poornima Vijayashanker: It's one person. A lot of times, we have multiple users or multiple personas, but in this design sprint, we're going to limit ourselves to one persona.
Charbel Semaan: You can. It's important in that unpacking and understanding to understand: who might the other people be?
Poornima Vijayashanker: OK.
One Key To A Successful Product Design Sprint Is To Pare Down The Problem And Who You Are Solving It For
Charbel Semaan: If there are multiple people, acknowledging that and having an understanding and awareness of that is great. Then you might, through the rest of the course of the sprint, you might say, "We're only going to focus on this one particular person or particular user of the product, because that's basically the breadth that we have." We can't really do much more. We know we've got other folks, but we're at least going to focus this sprint on this person.
Poornima Vijayashanker: Got it.
Charbel Semaan: And then that leads to, when you understand the problem, and you understand that person and how they're facing that problem, then the second step is to sketch. This is a fun part where...this is where most people want to get into brainstorming and get a lot of ideas on the table. One of the things I like to say—and I borrow this from what I've learned through IDEO—is to think with your hands.
Now you get to actually get pen to paper, pen to Post-its, and you get to sketch a variety of solutions. If you've got about six or so people in this room with you, even if you're running it with a co-founder or you're running it solo, this is where you get a chance to get a number, a variety of sketches out on the table or out on paper.
Poornima Vijayashanker: OK.
Charbel Semaan: The third step is to decide. You go through all the sketches that you've laid out, and through a number of exercises, like noting and voting and dot voting. There are a number of different ways to approach it...you actually decide: what will the blueprint be for your prototype?
Poornima Vijayashanker: Yeah.
Charbel Semaan: And then the prototype is the fourth step.
Poornima Vijayashanker: Yep.
Charbel Semaan: That's where you actually get to create a realistic version of what you want this product to be, or the service, for that matter, and you get it out to real users by the fifth step or the fifth day. That's where folks get to interact with what you've created, the prototype, and then you can learn and observe and understand what you can improve, or did you—and this is a key part—did you validate your hypothesis? Did you validate or invalidate what you had sought out to figure out?
How Dot Voting Works In A Product Design Sprint Gets Rid Of Decision Deadlock
Poornima Vijayashanker: There's a few things going on. Let's kind of unpack them in more detail. The first is, you mentioned this concept of voting and dot voting, which I like the concept a lot. I've started implementing it. But maybe for our audience out there who's not familiar, we can shed some like into what that is.
Charbel Semaan: Sure. One of the exercises after you've gone through sketching...let's say you're in a room with about six people. You're running the sprint with six people.
All six people have generated really interesting ideas and really interesting concepts or mock-ups of what the product might be. Dot voting and noting and voting, especially if you've decided ahead of time—and hopefully you have—who the decider is. There will be one person who's going to be the decider, and they get the majority vote, or they get extra votes.
Poornima Vijayashanker: Right. Two votes.
Charbel Semaan: Or extra dates. Exactly.
Poornima Vijayashanker: Yeah.
Charbel Semaan: One of the things that's fun is doing what's called a museum gallery, where everyone's mock-ups on their 8-1/2 x 11 sheets of paper and Post-its go up on the wall. Everyone has a chance to review everyone else's mock-ups. You can vote with dots, like a marker and dots, on the elements or aspects that you find compelling or you find interesting. When it comes to decision time after the voting and whatnot, you actually get to distill the best ideas from the entire group. That's one of my favorite aspects of the sprint, is that...some people say, "Oh, I'm not very creative."
Poornima Vijayashanker: Right.
Charbel Semaan: Or, "I'm not the designer." Or, "I'm not the engineer. I'm a technical person."
Poornima Vijayashanker: Yeah.
Charbel Semaan: What I have found is when you bring a collective creative together like that, then sometimes the best ideas come from someone you might not expect to come from.
Poornima Vijayashanker: Right.
Charbel Semaan: Then the voting allows for decision making, because you can't do all the features. The voting helps you distill it down to some of the key elements that you want to focus on for the prototype.
Who Needs To Participate In A Product Design Sprint
Poornima Vijayashanker: Let's talk about who needs to be involved in this process. We've already kind of mentioned that designers, engineers are great, people who are going to be building out that final prototype, but who, aside from them, needs to be involved?
Charbel Semaan: Great question. I found what's very important is to have someone who is part of the overall decision-making process. That can either be one of the founders or any of the founders or all of the founders, someone who's at a VP level or a C-suite level, depending on the structure of your organization and how large your organization is.
Poornima Vijayashanker: So maybe whoever understands the business goals?
Charbel Semaan: The business goals, for sure, and anyone who is even involved in sort of the direction and vision of the overall business.
Poornima Vijayashanker: OK.
Charbel Semaan: Certainly the people who would be doing the building itself and the designing itself, and definitely folks who are involved in the business side of things.
Poornima Vijayashanker: Why? I mean, doesn't that feel like they're micromanaging? Shouldn't they just trust their designers and engineers and let them run free?
Charbel Semaan: Yeah. It's a great question. One of the key principles of design that I've embodied and believe in so much is this two-part or two-fold aspect of inclusivity and collaboration.
You want to be inclusive and collaborative, and that avoids this waterfall effect where...if just the engineers and the devs and the designers are in the room, and the so-called business folks are out of the room, then it becomes this, "Now let's go back and take it to them and show them this, get approval, and then..." But when folks are in the room together, that's when those ideas can come out. More often than not, an idea gets sparked from one person, and especially if you embrace this yes/and approach.
It's like, "Oh, that's a great idea. You know, what if we also did this." Or, "Could we also try this?" "I didn't think of that. That's great. OK." And then you get back to that voting and say, "Great. We can't do it all, but let's distill them." You actually have a richer conversation and a richer collaborative experience when you include more aspects of the business.
Poornima Vijayashanker: Yeah. I think that's great that you're bringing all these people to the table, involving them in the process. Now, that's obviously a lot of overhead, right, for a founder or for a VP or some of these people to come in and sit in on a five-day design sprint. I'm sure there's going to be some pushback around it, which we're going to get to in the next episode. But for the purpose of this episode, how do we kind of constrain the time so that they don't feel like they're sitting in on a whole-day session?
Charbel Semaan: Right. I think there are a couple of ways of approaching it. One is to think about design sprints more as a mindset, or an approach. The pushback I hear a lot is this five-day—"We don't have five full days to have six critical members of our team..." I completely understand that. It makes a lot of sense. The response I often share to that is, "Would you rather invest up front in those five days, where all five or six of you or seven of you can come in, and you're investing that time, which is money. I understand. Would you rather invest that and have the opportunity to come out with something that yields you a real opportunity to engage with a real prototype with real people in five days instead of five months?"
Poornima Vijayashanker: Yeah.
Charbel Semaan: Instead of five months of a bloated product that you're not even sure is actually something that the people want or are going to use or pay for.
Poornima Vijayashanker: Right.
Charbel Semaan: You haven't validated. You may have those silos that you mentioned earlier. There tends to be tension. I mean, we've experienced it where there's tension between engineering and design and product and marketing and sales, etc. And you mentioned earlier about the business folks. It can be the founders. It can be the head of sales. It can be anyone who's involved in key elements of the business. When you bring them together for those five days, you tend to circumvent a lot of wasted money, wasted time, and I come back to decision deadlock. That's a key thing I've noticed, is the inability to get through that decision, that blocker, that keeps them from—
Poornima Vijayashanker: Yeah. Let's talk about that. Yeah.
Charbel Semaan: Sure. The key thing about the sprint...and whether it's five days...sometimes it can be compressed to three if done well. I've tried one. It's very hard.
Poornima Vijayashanker: Yeah.
How Having Constraints In A Product Design Sprint Leads to Clarity
Charbel Semaan: It's extremely challenging to do it in one day. I don't always recommend that. But the key part about the decision deadlock in the sprint—when you're using the sprint as a methodology, as an approach and a mindset, as opposed to fixating on the number of days and time—is it's going so fast, and there are so many constraints, that constraints lead to clarity.
You don't have a whole lot of time to spend on, should it be this way, or should it be that way? You're simply saying, "Here are the ways. Let's pick one, and let's try it. We're going to find out if it's validated or not—”
Poornima Vijayashanker: Right.
Charbel Semaan: “—and then we can run another one again."
Poornima Vijayashanker: I see. That's great. Yeah, because I think that's actually...I was going to ask the question around scope creep, but it sounds like if you're whittling things down, it becomes very obvious what that particular thing is that you're building, whether it's a feature or whatnot, and what the problem is that you're solving versus all these other problems that might be tangential.
Charbel Semaan: Right.
Poornima Vijayashanker: Yeah, you get that real level of focus, but I'm sure unifying people around what that one thing is is a challenge.
The Role Of The Facilitator In A Product Design Sprint
Charbel Semaan: It is. That's why it's important at the start of the sprint for me, as a facilitator, to first get permission and to get that commitment from everyone that I'm here to facilitate. I'm here to guide the process and really help extract or be able to foster and cultivate their ability to create and to go validate what it is they're trying to find out. The second part is having that decider in the room. When everyone agrees and commits to who the decider is...and for that decider to be convicted in their decisions and to truly commit to, "Lot of these things are great things we can do. We could save them for another sprint. We're really going to hone in on and focus on this particular aspect."
Poornima Vijayashanker: I could imagine that whoever the decider is needs to have done their homework and be really wedded to the customers, the problem. Are there ever times where they're not sure? They may need to say, "Oh, you know what? It's two problems here. Not really sure which one. I need another day to go back and do research, or a week," in which case, now you're holding up the sprint.
Charbel Semaan: Yes. Great point. Again, the beauty here is, because you're aiming for that fifth step or that fifth day to get the prototype in front of users, to take another day, which will turn into a week, as you said, is not helping anyone.
Poornima Vijayashanker: Yeah.
Charbel Semaan: Instead, note that you've got this second thing that you might want to do, or you think you have a hunch that maybe that's also a problem. It very well could be, and that's perfectly fine. Just let it be there.
Poornima Vijayashanker: Yeah.
Charbel Semaan: Pick one and go with it, and get to that fifth day or get to that fifth step. Get the feedback. Learn from it. And observe how folks are interacting with it, whether it's a feature, like you said, or it's the entire mock-up of a product, and then iterate and do it again.
Poornima Vijayashanker: OK. Yeah, so then there's not a lot of leeway for ambiguity, and you have to get comfortable making those firm decisions to keep the sprint moving forward.
Charbel Semaan: Absolutely. I think that's the key part, is to be convicted in your decisions and to keep moving forward, because this is a sprint.
Poornima Vijayashanker: Yeah, yeah.
Charbel Semaan: You're just getting to that finish line.
Poornima Vijayashanker: We've talked about these five days. Day one is sort of this brainstorming session.
Charbel Semaan: Day one's actually unpacking and understanding.
Poornima Vijayashanker: OK.
Charbel Semaan: You want to have a good understanding of the problem and who has the problem. Then you go into sketching a variety of solutions. The third day, you decide what you're going to prototype. The fourth day is the actual prototyping. And the fifth day is getting that prototype in front of real people.
How To Measure Success For A Product Design Sprint
Poornima Vijayashanker: OK. How do you know, once you've done these five days and put something out there, whether or not the sprint was successful?
Charbel Semaan: That can vary sometimes from team to team and people to people, and depending on the product and service. What I like to anchor to, though, is, did you get some level of a lightbulb moment or an a-ha moment?
Poornima Vijayashanker: Yeah.
Charbel Semaan: Did you learn something? If you didn't learn anything by the end of the sprint, then you may not have understood the problem as deeply as you thought you did, and you may not have understood the person for who you're solving it for.
Poornima Vijayashanker: Nice.
Charbel Semaan: I like to measure it in terms of, on one hand, there's the analytical side.
Poornima Vijayashanker: Sure.
Charbel Semaan: Like, do we get buy-in, or do we get people who are turning into customers saying, "If you're going to launch that and that actual product in the next two weeks or month, OK, here's my preorder"? Great. On the other side of it, have you learned something from it?
Poornima Vijayashanker: Mm-hmm. Even if it's an epic fail here, nobody likes it, they thought the feature was just crap, there's insight there where it's like, "Hey, we're not going to be building that."
Charbel Semaan: Right.
Poornima Vijayashanker: Or, "We're not going to flesh that out in greater detail."
How Product Design Sprints Help You Fail Faster And Cheaper!
Charbel Semaan: Like the majority of my products and ideas. I've learned something, though, or the team has learned something. If it's an epic fail, great. And this goes back to what I mentioned earlier. Would you rather have the epic fail and realize that in five days, or five months later after you spent tens of thousands of dollars or more? If you're outsourcing it, tens of thousands or more. If you've got an internal team, and you've got all your engineering and design and development time and dollars, that a-ha moment can go on the positive. Let's keep moving forward with this. We're onto something...or it's the, "OK, start over. But at least we only spent five days doing it."
Poornima Vijayashanker: Right. Yeah. I think that time investment is great. I think even in those epic failures, a couple things develop. You now have a process with your team. There's some comradery and some communication barriers that have been broken down. Then there's still some interesting customer insights. A customer telling you, "Hey, I didn't like this feature. What I was really looking for was X, Y, Z," that's a valuable conversation to have.
Just kind of developing, like you said, that confidence around, "OK, I'm going to practice active listening for what it is they're looking for."
Charbel Semaan: Great point. There are two things that...
Poornima Vijayashanker: Yeah.
How Product Design Sprints Bring Teams Together And Improve Communication
Charbel Semaan: You just triggered a couple of thoughts for me. One is on the team communication and bonding front. What I've noticed is the team ends up developing a common language and a common baseline or foundation to work with. The next time, I'll hear something like, "Well, why don't we go sketch this? Let's go sketch some...we're talking about a lot of ideas or a lot of ways that we could do this feature. Let's just sketch them out, and let's vote on them." Right? "And let's make sure one of us is the decider," or whatever it might be. The other part that you mentioned around the lessons that you'll learn from the actual people who are interacting with is, more often than not in my experience, folks don't simply say, "I don't like that feature."
Poornima Vijayashanker: Yeah.
Charbel Semaan: Or, "That didn't solve my problem. Thanks. Bye."
Poornima Vijayashanker: Right.
Charbel Semaan: They're usually walking through. And if you're facilitating that empathy interview and that observation time, you're asking questions like, "Could you walk through, think out loud, while you're engaging with this?" More often than not, they're going to say something like, "Well, this confuses me. I'm not sure what this does. I kind of wish it would do this."
Poornima Vijayashanker: Yeah.
Charbel Semaan: Or you could ask, "Well, what do you wish it would do for you?" You're going to learn so much more. It's not a binary: they didn't like it and you're going to walk away.
Poornima Vijayashanker: Right.
Charbel Semaan: You're still going to learn so much, like you said.
Poornima Vijayashanker: OK. We've run a sprint. We got some feedback. Maybe it was successful. Maybe it was not successful. But what's the next step?
Charbel Semaan: The next step, I think, is to understand: what did you get out of this? What was the yield? Did you learn something about what's working, and you want to double down on that?
You can double down on that in your existing product development methodology, whatever you have. Maybe it's agile, or whatever it might be.
If it's something that turned out to not work out so well, it was a failure—if you want to call it that—then you could think about, "Well, could we run a sprint on one of those other ideas that we sketched out?" Or taking what we learned from the people who interacted with it, it turns out, we had that in some of the sketches. Why don't we incorporate that next?
Poornima Vijayashanker: Oh, nice. Yeah.
How Product Design Sprints Help With Your Existing Product Development Process
Charbel Semaan: You may not run another five-day sprint the following week, but you now are so much more informed about your existing product development cycle that you could start to pull in some stories, if you run agile, or whatever your approach is.
Poornima Vijayashanker: OK. The idea is to use design sprints for moments where you've got a lot of ideas, you're not sure which one to execute on, and really for that quicker design feedback, but not as a standalone methodology for every week, we're doing a design sprint.
Charbel Semaan: I don't think so.
Poornima Vijayashanker: Yeah.
Charbel Semaan: Yeah. I think it works out better in the way you described it. I think, particularly, sprints are great when you start to notice a little bit of that clog.
Poornima Vijayashanker: OK.
Charbel Semaan: You're getting to that decision deadlock, or you've got a problem you want to solve, but you're just grinding on it.
Poornima Vijayashanker: Right.
Charbel Semaan: The sprint allows you to just get moving. It allows you to go from thinking to action.
Same when you have a new idea. You've got lots of new ways that you think...well, we think we might be able to roll out a feature that could generate another hundred grand in revenue. Or we think we could branch off the product. There's this whole other market, and that could be a million-dollar product on its own or more. Well, run a sprint on it instead of thinking about it or figuring out, “could it be? Should it be? What do we do with it?”
Poornima Vijayashanker: I'm sure other teams—maybe marketing, sales, customer support, all these other teams out there—are probably going to start embracing design and using it. Have you seen the design sprints used for other things?
Charbel Semaan: Yeah. Actually, this is my favorite part.
Poornima Vijayashanker: Yeah.
Why Product Design Sprints Aren’t Just For Product Teams
Charbel Semaan: It's not just for product teams, at least anymore. Two favorite examples of mine, where teams that you might not expect have used design sprints and they've used them successfully: learning and development team at Medallia used a design sprint. We ran a design sprint to think about: how could we start scaling training across the entire company through video and through online learning? We ran a sprint where we had a scrappy video set up in one of the small corner offices, and we got out an example, a prototype, of a training video on a completely low, tight budget. It showed a proof of concept to the team and the entire organization what's possible.
My other favorite example is my friend Brian Bautista at SoundHound. He's the customer support person and customer success for SoundHound, and he's been transitioning, actually, and has officially transitioned to the product marketing team because of a prototype and a sprint that we ran.
Poornima Vijayashanker: Cool.
Charbel Semaan: Not necessarily on the product itself, but he was helping educate on the product and wanted to ensure that people were using SoundHound and Hound in the best possible way. What he wanted to do was test a new type of video. It was more personable. Could showcase a little bit more of the humanity of the brand and the personality of the brand. In eight hours, believe it or not—
Poornima Vijayashanker: Oh, cool.
Charbel Semaan: —ran a prototype on what that video could be, takes it to his VP of marketing, and she loved it and greenlit more videos.
Poornima Vijayashanker: Well, thank you so much, Charbel, for teaching us about design sprints today.
Charbel Semaan: My pleasure.
Poornima Vijayashanker: Yeah. For all of you out there who are watching and listening, Charbel and I want to know, is there something that you've been stuck on? Maybe a decision deadlock when it comes to a product or a service, or even something in your personal life. Let us know what it is in the comments below this video. That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode, where we'll dive into how you can evangelize design sprints at your organization. Ciao for now.
This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.