Skip to main content

Product Management Webinar: Product Leadership

How to get out of the weeds as a Product Leader

In this webinar, special guest, Saielle DaSilva, Product Leader and Director of UX at Cazoo, and host Janna Bastow, CEO of ProdPad and inventor of the Now/Next/Later roadmap will explore how to get out of the weeds as a product leader.

Recently, Saielle’s team experienced hyper-growth, that increased her team to 60 UX folks. As you can imagine, this came with lots of challenges, including how to scale, where to let go, and how to know where letting go was the right thing to do. We tackle these questions and much more in this webinar.

Saielle DaSilva, Director of UX at Cazoo

About Saielle DaSilva

Saielle DaSilva helps companies find their customers, meet those customers’ needs, and do it in a way that’s viable for building businesses. She has worked for companies big and small on everything from network infrastructure to IoT and machine learning. Companies like AT&T, Amazon, and Pivotal have worked with Saielle to advance their design, data science, and product management practices. 

Saielle advocates for diversity in tech organisations and helps companies apply user centered design to internal processes and hiring. Saielle is currently a product leader and Head of UX design at Cazoo.

Key Takeaways

  • How to become a pro at delegating work 
  • Encouraging and facilitating your team to take on new challenges 
  • How to change your leadership style to focus on clarity over control 
  • How to collect and utilise feedback from your own work
Flying ProdPad Dot

[00:00:00] Megan Saker: Hello folks. Welcome to our webinar today on convincing your stakeholders that Now-Next-Later works best. I’ll just introduce myself very quickly. I’m Megan. I’m the CMO here at ProdPad. And yeah, what we’re going to cover today is how to go about winning buy in from your stakeholders, from your team, to make the move to the Now-Next-Later roadmapping approach.

How to get everyone convinced that it is the right decision for your organization. But first Just a bit of housekeeping. We are going to make sure there is time at the end for a Q& A. So please, whenever you think of a question whilst Jana is talking, please pop it in the Q& A box. So you’ll see across from the chat.

There’s a box there specifically for those questions. So throw them in at any point during the webinar. We’ll make sure there’s time at the end. We’ll come back to them and go through them on. Janet will answer them. Also, just to say that this webinar is just one hour. Apologies to any of you that have a daunting 19 minute slot there in your diary.

It’s not. We’re going to keep this to an hour. Obviously feel free to use the chat at any point. We will, after this webinar, send you a recording and the content that Jana is going to be sharing today is actually a slide deck that you can download yourselves as a template and use it, edit it, adapt it, do whatever you want, use it with your own stakeholders.

So let me introduce you to Janna Bastow. Many of you will be regular ProdPad webinar attendees and know Janna. Jana is a product management guru. She’s in fact, along with her co-founder of ProdPad Simon Cast, the inventor of the now next later roadmap. She’s co-founder of Mind the product.

So today, as I say, she’s going to walk you through all the arguments you’ll need to present to your team and your stakeholders to win their buy in, to move to agile roadmapping, and then our next later format. As I say, Jenna is going to take you through a ready made presentation slide deck that you’ll be able to download.

Edit and use yourself and we will email that link to you at the end, but you’ll also see a QR code that you can snap at the end. Without further ado, I will hand you over to Janna. 

[00:02:32] Janna Bastow: Excellent. Hey, thanks so much, Megan. And hey, everybody. Thanks for coming along today. Reason why we chose this subject is because it’s the one that vexes product people the most.

We talk about now and X later until the cows come home and product people get it. But when they try to bring it. Into their teams. This is where they start hitting objections and friction. Now we have coached literally thousands of teams, helped so many teams move from timeline roadmapping to now next later, we’ve got a few tricks and ways that you can start, bringing them on board with this. So we’re going to share that with you today. And as Megan said, we’re going to be using a particular part of the slide deck that you can take for yourself to use in house to convince your product people or your, the rest of your team. Sorry, not the product people, the everybody else that now next later is the way to go.

So let’s jump in. But before we get too far, I just want to introduce you to ProdPad. Some of you are already using it, which is great. Thank you so much for your support. Some of you, this might be new to you. ProdPad is a tool that was built by myself and my co founder, Simon, back when we were product managers ourselves.

Basically because we needed tools to do our own job. We needed something to keep track of all those experiments and all that customer feedback and to create a roadmap that would show people on the team where we’re going. So we built something. And so what we realized is that ProdPad was something that was going to give us control and help us organize our work and provide transparency into the product management space.

So people stopped wondering what us product people were up to and why we kept making decisions like we do. And what it does, it helps you create a single source of truth for your product decisions, for your product work. So nowadays it’s used by thousands of teams around the world. It’s a tool that you can try for free.

We have a free trial. You can jump in and start using it right away. And we also have a sandbox mode in ProdPad. That’s basically a version of ProdPad that’s preloaded with example data, like lean roadmaps and OKRs and feedback and experiments and all this other stuff. Sat in one place so you can move it around.

You can try it out and you can see how it’s going to work for you. And our team is made up of product people. So it was founded by a couple of product people and we’ve got product people throughout the team as well. And so we are constantly looking to learn and iterate and adjust. So we’d love to hear your feedback, jump in, give it a try and let us know.

And I also want to highlight some really cool stuff that we’ve been working on, right? We’re constantly iterating ProdPad, as I said but one of the really interesting areas that we dove into. Last year was AI, right? We got our hands on the the GPT API and started playing around. And we realized that we could enable product managers to reduce so much of their grunt work by making it easy to generate ideas and to flesh those ideas out, have it answer questions like how you might measure target outcomes or whether this idea is actually any good, you can compare those ideas to your vision.

You’ve got your objectives. You probably, a lot of you are probably working on your OKRs right now. You’ve got your high level objectives. This will help you brainstorm key results and not just any key results, but we’ve tweaked it to be to give you results that are outcome focused and leading metrics to measure your objectives by.

And it gives you feedback on stuff, right? We didn’t just want something that generates stuff. We wanted something that can be like your sidekick, like your coach. And so you can take things like your product vision, which you’ve gotten product pad, and it’ll give feedback on it and tell you how to strengthen that vision and iterate on it.

And we’ve also built out, this is the newest piece of it, a chat bot that you can talk to and get product insights, product advice, but also it knows what’s going on in your product pad account. So you can ask it questions like. Hey what should we work on based on what our customers have been asking for?

Or can you help me give, can you give me feedback on this roadmap? Or can you help me identify things that we could put on the roadmap that would match with our objectives? So it has this sort of insight and it’s available for you to jump in and give it a try. So we’d love your feedback on that.

 And ProdPad is a tool that you can start a free trial for. So jump in, give it a try and let us know what you think. Now on that note, I want to start talking you through how to get people over to the now, next, later format of ProdPad, right? Because of a roadmap, which is the format that we use within ProdPad.

Um. The thing is that you’ve got to think about who you’re presenting to, who is it you’re actually trying to get on board. You’re going to have a lot of people often within your company who don’t want to move away from a timeline roadmap for various different reasons. And so we’re going to look at how to get your exec leadership team on board, show them the benefits of Why you should be working in an agile roadmapping format, like now next later, as opposed to the timeline that you’ve been using for the last few years.

But also we’re going to help you get other departments on board with this, right? So let’s say it’s your sales team who is holding onto that, that timeline roadmap and those delivery dates that you, they used to promise. And what about your marketing team, or what about your customer facing teams?

So there’s different stakeholders within your business who might have different reasons why they object. To moving away. And so we’re going to give you some tips on objection handling. So really you need to understand who it is you’re going to appeal to, who it is in your particular company, like who is your tricky stakeholder and you might have more than one.

And from there we can start looking at ways to successfully win them over. So before we craft our arguments on to persuade these stakeholders let’s try and understand the reasons why. They’ve got preferences for timelines. What is it that they think timelines give them? What makes them think that they’re necessary?

Let’s start at the top here. The, your big bosses, bosses, your exec team, they like deadlines. Deadlines give them a sense of control or at least a sense of security that everything’s going to go according to plan and timeline blankets are like a security blanket for them. They’re a comfort blanket.

They reassure them that everything is working. In some organizations, you can find that the business leadership will lack trust that any department is not explicitly commercial, so your sales and marketing teams that they don’t trust that they have a mature enough appreciation for the commercial imperatives of the business.

They think it’s necessary for the non commercial teams, those who don’t have enough revenue, who don’t focus enough on revenue to appreciate the urgency to have deadlines and dates. So those people who do understand this urgency can push them and drive that pace. So this is how leadership can easily enforce pace and help them clearly see when it’s not being delivered.

But it’s also important to understand that sometimes leadership, especially in organizations who are transitioning from that traditional business model to more of a platform or SaaS model can have a mindset. That’s a bit of a hang up. From the days of selling individual one off project products or instances of a product to individual customers, right?

They’re doing custom work. so It’s not uncommon to have deadline expectations coming from your exec team as a hangover from that, I call it the agency trap, right? When companies are working in more of a an IT project or agency model. And put it this way, software agencies need dates and deadlines because they’re running with a very defined.

Project right? A client gives them a scope and a time and a cost and they deliver to that. They have billable hours and a specific quote to meet. And these are paying customers waiting for delivery of the product by a certain date and possibly contractual obligations to meet. But if you’re not an agency, this isn’t how you should operate.

It’s what I call the agency trap when product companies act like agencies taking on custom work, and it takes away the time that they have to spend in discovery work. So we’re going to address that one. Um, also bear in mind that some of the pressure you might be feeling from leadership. Is actually transferred pressure, right?

It’s from outside forces. They might have stakeholders of their own. It might be investors or customers who are pushing on them to get these dates. So you’ll need to show the execs how they can manage investor or board reporting, or, manage other teams around these dates as well. So this is why getting your execs on board is so important.

Now, sales teams are the. Other particularly vocal stakeholder group when it comes to ditching the timeline, right? This is the other group that’s going to give you problems. And why is that? What is their problems? tHey might run into fears. They might have fears like they’re no longer able to make commitments to their prospects, which screws up their plans on how they’re going to close deals.

This is particularly. Painful if the company is running in that sort of agency style mode, as opposed to thinking about themselves being a product company. They’re worried that delivery is going to slow down if there’s no deadline pressures. So similar to what your execs sometimes think. And.

They’re also sometimes afraid that they might look foolish if the road map pivots, if you change something that’s on the road map. So we’re going to talk about these types of fears as well. And then you get marketing, right? So marketing might be concerned with how they’re supposed to plan campaigns and launch stuff without a timeline, if they don’t have an idea as to when something is going to be out there.

But we can talk about how we can work with these fears as well. And then your customer teams are going to be primarily concerned with how they can confidently respond to customer questions. Customers are going to be wanting, wondering what it is that you’re actually up to and whether you’re building into the direction that makes sense for them.

And so your customer teams are going to want to cite as to what’s going on as well. So we’re going to look at how we can win over each of these stakeholders and get them all on board with the now next later way of working. The way that I really recommend doing this Is to get your stakeholders in a room and show them the light, show them what they’ve been missing because oftentimes they don’t understand why you’re making this change.

And so if you can explain to them. Where you’re coming from, what the value is for their particular function, and for the business, you can start getting people on board. One of the best ways to do this is to get people into a room together, a Zoom room is fine, right? And what you want to do is share with them the values of a Now Next Later roadmap and make sure that they’re on board with it.

So what I’m going to do is I’m going to show you some slides that we’ve created that we’re going to hand out to you afterwards that you can use. For your own stakeholders. So these next slides are ones that you can take home and the slides themselves also have cues in the slide notes, presenter notes.

So you can follow along and use that to get people on board. So keeping in mind that we are coming from a place where we have convinced or we’ve helped people, thousands of companies convinced their bosses and their teams to get on board with it. This is basically the formula the points that you can use now, because this is a take home thing that you can use for your own company.

Feel free to make adjustments, right? If there’s a different stakeholder you want to take in or take out or, address a particular concern, change these around, right? Chop and change these as you see fit. But here’s a way that you can start doing it. So imagine that you’ve got your hands on this deck and you’re convincing the rest of your stakeholders.

Here’s where you might start. So first of all, you want to bring them in and start talking about why Better Roadmap is going to get you better results. This isn’t just about you removing the pressure of having to put dates or you’re not too lazy to go get estimates from the rest of your team.

You’re doing this to get better results for your team. This is about driving high value outcomes for your company. So this is the frame of mind that we’re going to start this argument in this conversation in uh, and what you’re looking to do is help them move from timeline road mapping to agile road mapping.

So point out. What it is that you’re trying to do your proposal here is to move from one format to the other format. And what we’re going to do is talk them through what the now next later format is, and how the timeline roadmap format hasn’t been working for them point out the cracks in this facade and start.

Bringing forward this new idea. So again, this is very much an outcome focus. This is all about delivering solutions that are or to strategically important problems and measuring those results. So you’re going to provide more to them. You’re not taking something away. So what you’re going to be doing is you’re gonna be making a promise, right?

You’re going to be promising these different things that you could do for the company. One, like delivery will speed up. You will be able to deliver faster using a a timeline sorry a now next later roadmap, but you’re not caught up in trying to do all of the project management estimations before you jump in and try to solve the problems you’ll be shipping more.

You’ll be driving better results, right? You’re driving towards outcomes rather than just a whole bunch of outputs, a bunch of features. You’ll be responding faster to new opportunities and therefore not missing opportunities in the market, which is so important in this world when everything just changes on a dime every.

A few months, it seems, uh, you’re going to be better strategically aligned. So you’re going to be using cases like this to make the, you’re going to be making a case around how it aligns the whole team around it by having a simpler roadmap that identifies what your strategy is, as opposed to just having a list of features and things to do, and you’re going to be operating with greater efficiency, less waste.

There’s a reason we call it the lean roadmap format is that it’s less wasteful. And finally, you should be getting, you should be able to make the case that it will help you retain staff, right? No more sad developers who are leaving because it’s full of tech debt and, they’re sick of building just feature after feature with no real cause.

So I’m going to expand on each of these more later so that you have the points to drive these home. And those are going to be included in this deck. So first of all, make sure people know what you mean by agile road mapping and we use the term agile road mapping now next later road mapping and agile road mapping.

They go all by different names. Call it what you want, right? Call it whatever seems to work for your particular company. But I like the term. Agile because it speaks to that broader approach, the Agile methodology, which is, it allows for flexibility. It’s there for continuous improvement and rapid response to change.

And so therefore Agile road mapping has been adopted into road mapping or the Agile methodology has been adopted into your road mapping methods. And that’s how you get this now next later. So we’re definitely going to try to focus and sell people on the fact that this is outcome, not output focus, right?

You’re not just taking away dates. You’re actually giving them something, the outcomes here. You’re bringing the company into a more customer centric way of thinking so that the problems are organized around. Customer problems to solve. yoU are structuring with broad time horizons rather than rigid deadlines.

And so this is really important because this gives you that flexibility, but still gives people a sense of direction and pace and, distance how far something is from being done now. And really most importantly, it’s flexible. It gives you space for learning. So these are the things that you’re going to want to share with people as you are getting them on board with your.

Now next later way of working so you can then introduce that now next later road map as a specific way of doing agile road mapping. So this is the approach that was invented by myself and Simon. It actually came out of the fact that we were building prod patents early days and started looking at ways that we could build a road map that wouldn’t track people.

And so really we wanted to end the focus on features and deadline in favor of a greater emphasis. On discovery and it’s now being used by literally thousands of teams around the world. So many product managers are now using this and we’ve got proven cases of how this has helped team deliver more and be more outcome focused.

It’s also an easy to understand format, right? It’s it’s not convoluted with a whole bunch of junk. It helps you, it’s inherently strategically aligned, because I like to think of it as a prototype for your strategy, a way to outline The, your high level strategic steps before you dive into deep it gives you that flexibility so that you can change things on the fly based on insights that you get at the strategic level.

And it’s inherently outcome focused, right? Each of the things on your roadmap are going to be tied back to the outcomes that you’re looking to get for each of them. And it’s the most customer centric approach to roadmapping. bEcause what it’s doing is giving you clarity on what those customer facing problems are and outlining how you’re going to go about solving those problems.

So then you can start diving into deeper, right? So how does the the now next later roadmap work? As I’ve said, it’s often referred to as a lean roadmap or a time horizon roadmap. Now next later are the time horizons. The ones that are in the now column are your well understood problems with defined solutions and committed Development resources.

This is stuff that team is working on right now. You’ve got your next column, which is the problems that are generally at design or discovery stage with some assumptions that you need to validate before committing those resources. And then you’ve got your later column, right? These are your aspirations.

These are the things that are a bit fuzzy and are still taking form. They’re on the horizon in the distance. Although we do know that we want to solve them if we want to get to. That, the big vision for our company. And so basically, as you start working on things, you’ll take things from your later and you’ll break them down into more detail and they’ll move into your next.

And then you’ll break them down in more detail and they’ll become part of your now, and it’s not fully linear. Anybody who’s made a roadmap knows that your roadmap is not linear. And this isn’t trying to be, what it’s doing is mapping out what you understand. The product space in front of you looks like if this is what we tackle now, then what are we going to tackle next?

And what are we going to tackle further off in the distance? And as you take steps, think of these cards on the road map is stepping stones. As you take steps and you get closer to that future vision, you’re going to adjust and you’re going to say, Oh now that we can get, we can see more, we might actually take this direction instead.

And you shuffle the direction of these cards depending on what you learn. So it’s inherently a flexible roadmap that changes as you learn more. You also might call your roadmap columns different things, right? I, one of my favorite takes on it is calling the Now, Next, Later columns Doing, Discovering, Dreaming, because they outline the things that you’re going to be doing.

At those particular times during the, that far out on the roadmap, the things that are in the doing or what you’re doing right now, things in the second column or what you’re discovering. And the later column, the third column is you’re dreaming, right? Here’s where you’d like to get to, but you’ll figure it out as you get a bit closer as well.

Other teams like to wean themselves off the timeline roadmap. One way that really helps to work, helps people move over is to move from their usual timeline roadmap into something that has more of a fuzzy this quarter, next quarter, Q3 plus, right? And that way you’re getting people used to this sense of, time horizons, and they’re getting fuzzier as they get further away but not taking away those dates on day one. Once they get used to the, the Q1, Q2, Q3 sort of format, you can start bringing them closer and changing the wording to now, next, later, and that way you’re not stuck with things within particular columns.

But, what’s important is that understanding that the maturity of initiatives in each and in each horizon. So now is where you’ve got a granular area of focus. And whereas initiatives that are in the. Later are broad high level. They’re subject to change as you discover more about them.

And as initiatives move from right to left, they develop, they evolve, they, the mature and by the now column, they’re known pieces of work specs that are being written. Delivery dates are being planned. Development work is being done. aNd I can see that somebody Chris is saying in the the chat here that they found that Q1, Q2, Q3 to be a good safety feeling for people, right?

It feels more tangible to them. And I agree with this. It’s a really good way to get people on board with this. And there’s no shame in having. dates like that on your roadmap, on your now next later roadmap, because you’re still going to be getting most of the benefits of it. It’s still going to be outcome focused.

It’s still going to be customer centric. It’s still going to be easy to understand. And it’s always something that you can change later as people get more used to the three column view. So how it works, you’re gonna be talking to people about how you’re going to be populating this roadmap with or basically instead of populating your roadmap with features to be built your now next later roadmap contains what we call initiatives or roadmap cards, or, these chunky blocks, the big white blocks on the roadmap.

anD I like to think of them as problems to solve, or opportunities, or areas of focus, and within those initiatives are then a series of different ideas that could be worked on to try to solve that problem. We call them ideas in ProdPad Land, but I like to think of them as experiments as well. Because what you’re basically saying is we’re going to find several ways to experiment and solve this problem in order to reach the goal that’s on our roadmap.

And by using experiments, it gives you a little bit more flexibility to to think about how you’re going to solve this problem. You’re not meant to do all your experiments. There’s a bunch of ways that you could solve this problem. And so really you’re changing it from our roadmap is a list of things that we will do.

And instead, it’s a list of problems we want to solve and then broken down into how might we solve this problem. We could try this, and this. And as you work your way through, you get better at understanding how that problem is going to be broken down. And you start tackling that problem. You start working towards your outcome.

So the other key thing is that initiatives on the roadmap should be linked to at least one of your core product or company objectives, right? Those objectives are the that the green line or the blue line or the pink line at the top. These are all things that help you identify the why.

Why are we doing this? Why would we solve this problem? And so you should be able to create a roadmap that you can collapse down and ProdPad offers these collapsed views. You should be able to collapse it down and squidge your eyes and just get a sense as to what your roadmap is about, what your product strategy is.

Are you growing your user base up front and then getting revenue? Or are you going to tackle revenue and then market share or tackle the churn problem first? So you should be able to see these almost trends within your roadmap. That will help outline what your overall product strategy is. And then you break it down into more detail about what problem you’re going to solve.

And then break that down into even more detail about how you might solve that problem. So that’s the gist of how it works. Now there’s more on this that we can teach you. But we’re not going to dive into that because there’s a lot of nuances about how to do road mapping. I’ll show you a course.

Afterwords that allows you to dive into this stuff in more detail. But we’re all at this level when you’re bringing this to your team, they don’t need to know all the nuances. What you want to do is sell them on the benefits. So what is it that they actually get from this? Let’s go through these.

I mentioned this is the same list that I mentioned earlier. So we’re going to dive into these in more detail. bEcause NowNextLater does not rely on exact deadlines for its structure, teams aren’t asked to plan schedules ahead of time and commit to exact dates which are, for the most part, entirely fictitious this far out.

So that requirement for dates almost nearly nearly always sees teams Bake buffer time into their estimates in the hope of mitigating missing those deadlines and then being blamed and then feeling the pressure for that. Um, What often happens if you’re adding a whole bunch of buffer time to your work and putting that on your roadmap is that if you’ve ever heard of Parkinson’s law, it’s the law that states that work expands to fill that time.

And so what was once a cautious estimate becomes the actual time taken. You rarely hear of teams finishing things early and then cracking on with the next thing. Things are always coming out just about on time or a little bit late, regardless of how much time you said up front you were going to spend on it.

So the broader time horizons of pro of the NADx later means that no one is baking in buffer time just for the sake of having it. And things actually get delivered faster. If things move faster, then more work can get done, right? More features are built. What you’ll find is teams using NowNixLater deliver more, more often, and get things out the door faster than teams who have to spend all that time doing the planning and figuring out exactly how long they’d want it to sit on the roadmap, and then try to line them all up in a row.

Agile roadmapping and the nanoslator roadmap means that your team is going to move faster and ship more. This is a really key selling point and it’s sometimes a bit counterintuitive. People think that having deadlines is going to get them to move faster, but it’s not true. Deadlines have never inspired people to move faster.

What it’s really going to do is mean that you’re having to protect your butts and not get as many things put on that roadmap and therefore deliver less.

One of the other things that you can emphasize here is Talking about the outcomes that you’re going to be getting rather than the output that you’re going to be focused on, right? So each roadmap item is focused on a particular outcome, solving a particular problem for the customer and for the business.

So this emphasis means that the product team is accountable for an outcome, not just those outputs. This is really key because, remember, delivered does not mean done. Results have to be measured and iterations and improvements made where needed. Products bloated with ineffective features essentially become a thing of the past, right?

You’re not going to want to worry about that. So with Now Next Later, teams are motivated to drive real value and deliver against their objectives, not just have a feature because the roadmap said to have a feature. So you’re declaring the problem. Not the solution and the roadmap is a space to discover what’s actually best and the best way to solve that problem.

So roadmapping and the now next later format, what you want to really enforce is the fact that it’s there to help you deliver greater value to the customer to the business.

Other really key thing that you want to drive home is the flexibility afforded by having this timeline or this time horizon way of working, right? You’re focused on those outcomes. You’re focused on the time horizon, but really you’re focused on the order in which you’re looking to tackle things.

And you can adapt that order, right? You might finish one thing and then realize that the next most important thing is not what you thought it was last quarter. It’s something new because. The market’s changed or people reacted differently to what it is that you built last quarter. So the roadmap format should give you space to adapt.

Naturally, as you learn more, so there might be ways that you need things you need to respond to. So there might be new discoveries from user research. There might be market research. There might be a competitor analysis. That’s been done. There might be shifts in the markets, just in the economy. Lots of things happen.

We know this now. There might be new opportunities like a. AI comes out or the next big thing comes out and you realize that there’s a huge opportunity to build that in where you no longer beholden to building, whatever it said you to build in June, just because June is here. You should build what’s most important for the business as that point comes up, as that time comes up, as that opportunity comes up.

And there might just be changing strategic priorities, right? The company might have to shift its goals and therefore your roadmap needs to be able to shift as well. So the now next later roadmapping approach, what you really want to drive home is that it’s going to be, allow you to respond faster to threats and capitalize on new opportunities, right?

You’re going to be able to adjust your plan as you go.

Other key point is that the now next later format. requires all initiatives to be linked to a product objective or a company objective, right? This is an IR clan way of ensuring that the team is prioritizing and working on things that actually bring strategic value to the business. You can’t put things on the roadmap.

Just because you wanted a new feature, you’ve got to be able to say what features does this problem solve? And why do we want to solve this? If you can’t answer those two questions, then it probably doesn’t deserve to be on your roadmap. So it’s a really good forcing function to get your team thinking about the strategy and aligning the work that’s being done to that company or product level strategy.

So really drive that point home about that alignment and then it’s also going to help you operate with greater efficiency. Everyone loves to save a bit of time and not waste their time doing stuff that ends up not being used, right? So the now next later time horizons stop product teams from wasting time planning out super detailed schedules that are far in the future about, what’s going to be delivered and when oftentimes that stuff.

Just ends up getting reworked or thrown out or ignored because they naturally have to change along the way. And it’s also hard to estimate that far out. And so the more that you’re doing it, the more that you’re making it up and that’s not a useful. Way to spend your time as a product manager.

You can be spending that time talking to customers or learning about the market or, figuring out the best thing to build next, as opposed to trying to figure out how long something’s going to take in three months time, it doesn’t matter and you don’t know. So it drives efficiencies and it’s going to unlock more time for higher value product management work, really drive this point home as well.

And then the last one, this is really key for people who are in the exec team are Drive home the fact that it makes for happier teams and therefore better retention. What you’re really getting here is the fact that you’re, when you remove the practice of setting deadlines too far in the future, you alleviate the pressure and fear that comes with hitting unrealistic dates.

The delivery dates. Put in place with now next later way of working are only set once work has been defined and specifications have been written. You’re not trying to plan way out and then hold people to these dates that haven’t been that aren’t realistic. 

What you’re really looking to do here is to what you’re actually looking to do here is also it reduces the amount of tech debt, right? If you have a whole bunch of. Projects that end up getting delivered one after the other, but you end up cutting it close at each turn, you’re going to start accruing tech debt.

And that tech debt stacks up, creates a tech code base that becomes unworkable. And you end up with teams that have just tons and tons of difficulties building things, unhappy developers who end up. Leaving, right? And so having this way of working helps to retain your staff and reduces your hiring spend, right?

You don’t have to replace people, you don’t have to train people up. fLip this around the other way as well, right? You want to tell them about the benefits, but you also want to give them the warning about what happens If they don’t, right? So delivery is slower, tech debt builds up, and you end up with a tech project, a tech stack that needs to be rewritten opportunities end up being missed, right?

You’re too blinded by what you said you were going to build at the beginning of the year, and you’re halfway through the year now, that you have to go build whatever it says to go do in June, that you don’t look outside and say, oh maybe we should be building this instead, because this is going to solve the right problems for us.

You end up with people being less accountable for the results, and you end up with your brand reputation sometimes being damaged if you build the wrong things, or if you end up missing promises that you’ve made in this roadmap, you end up losing people in the team if they’re not able to work in a autonomous way to solve the problems in the best way, rather than just cranking out feature after feature, which is soul destroying and oftentimes money is wasted building the wrong thing.

So many teams end up just building stuff because it seemed like a good idea when they mapped out this road map at the beginning of the year and aren’t actually building the right stuff. So other really key thing is that you want to make sure that you’re getting certain you want to make sure that people on the team are feeling this win, right?

So a lot of what we’ve spoken about so far are benefits for the wider team or for the exec team. You really want to be driving those benefits home. But also you can use these slides here to tell, to talk the sales team through or talk different mark different Stakeholders through, and we’ll go through a bunch of different ones as to how they’re going to win doing this.

So this is a win situation. You’re not taking something away. So for sales team. They’re going to end up with better objection handling, right? So presenting your roadmap through problems to solve can provide your salespeople with a simple way to handle objections and answer needs, right? If a prospect says a competitor has one feature that we don’t, the salesperson can drill into the problem that the feature is trying to solve, and then they can scan.

And then they can start explaining a different feature that we might have or soon to have that solves that problem and, maybe suggest that it’s a better way of solving it. So it’s driving salespeople to think about the problems that people are having, as opposed to just saying tick box, do we have this feature or not compared to our competitor?

You’re really truly getting people to think about the problem view. It’s also a safer way to share the roadmap, right? You might have two different types of salespeople, right? You’ve got one who is smart enough not to show the timeline roadmaps with prospects. But we all know some salespeople will just take that roadmap and share with prospects and go ta dum, go Take your pick.

What would you like to buy? And when would you like to buy it? Because we’re going to have all these cool features, which we know the roadmap never gets delivered. A timeline roadmap never gets delivered as. It was written out. And so it’s dangerous, right? You end up with salespeople who get mud on their face because they’ve made promises that the team can’t keep.

And so with using a now next later roadmap, you’ve taken the dates off. You’re not talking about specific features that can be delivered by specific dates. You’re able to turn that around and say Hey, here are the problems we’re looking to solve. We’re going to go from here to here, these types of problems.

And you’re not making promises of specific things that are going to be delivered for them. But you can use this as an opportunity to discover whether these problems align with your customers. And if one customer comes back and looks at your roadmap and says, Oh, this isn’t right for us. It’s probably not a big signal.

If a lot of customers look at your roadmap and say, Whoa, I can’t believe you’re solving this problem before you solve this problem. That’s good insight. And that might be a time that you can adjust that roadmap. So you can work with your salespeople to share the roadmap as you have it, get feedback on it and use that feedback to inform you as to whether you’re heading in the right direction that your customers care about, that your market cares about.

And it’s a huge misconception that now next later roadmaps cannot have dates at all, one of its biggest misconceptions. And this is the thing that often holds sales teams or even execs back. If a huge deal hangs on a particular feature being live on a particular date. Then you might be able to work that out, right?

You can it doesn’t mean that you don’t have dates on that roadmap. It means that you’re not driving that roadmap by dates. So something has to have a hard date. You can show that on the roadmap. Now, what you’re giving up is that your team does need to do the project management work to line up to get that.

But you’re still able to show specific dates. You’re still able to communicate dates where they are strategically important. And externally driven, right? So it’s not just about putting arbitrary dates on everything, but if something does need to be communicated, you can still communicate that on a now, next late, now, next later roadmap.

iF you’ve got a sales team on board with, or if you’re trying to get the sales team on board with the now, next later roadmap and they’re pushing back on it, You might find that they’re struggling because they’re not used to selling the product that exists today, right? This can be a tough conversation to have because sometimes it means that the sales team just isn’t up to the job, right?

They’re selling something that doesn’t exist yet because it’s easier to get somebody to just come along and state what they want rather than working. Harder to find the types of leads that they actually do that actually are going to make use of your product as is. So really key thing that you can be doing is working with your sales team to identify your ideal customer profile, your ICP, and they should be able to.

Target the right types of leads that are going to find your product useful for what it is today, rather than just constantly throwing it out to anybody and bringing in anybody. So you’ve got to be that, that that voice to say, here’s who is going to use our product. Here’s the jobs it does solve. Go find people who need to solve those jobs.

So that’s a a really key point is that you’ve got to work with your salespeople on what your ICP is. The marketing team is often afraid of moving to the now next later format because they think that they need a deadline so that they can launch their. Features they can launch their campaigns on the same day that you’ve launched your features.

And that is always fraught with difficulty because what you’re trying to do is you’re trying to line up a development project to land on the same day as a marketing project. And if that development project gets pushed back, your marketing project. has jumped the gun, right? Or they’ve lost money or they’ve lost time.

What you want to do is you want to separate your hard and soft launches, right? So your soft launch comes out and from that point you’ve got a version of the product that is in a feature flagged area of your product or is in a beta subdomain or is, turned on just for specific customers. And what you want to do is you and then you can turn this thing on just for your internal users or a specific set of users, maybe a beta group of people, and then from there, marketing can pick it up and they can plan out the biggest bangest launch that they can imagine, right?

But now, instead of trying to tie their launch date with your feature launch date. They’re starting from a point that the feature already exists. They can get pictures of it. They can get videos of it. They can start getting testimonials of it in this soft launch format. And then from there, they can plan out a huge launch, right?

Whether this takes them six days or six weeks or whatever it takes them to do this launch. It separates your soft launch from your hard launch. And at that point that hard launch goes out, you know that feature is going to be there because. It’s in a feature flag mode. It’s in beta. It can just be turned on as opposed to you trying to figure out if you can actually get things out on that date and possibly losing scope and quality along the way.

So make sure that you use the soft launch to give your marketing team heads up on Where they’re going with it use that soft launch to give them confidence in the feature and, show them what the feature is actually going to be as opposed to them hoping it matches the original design specs from earlier on.

And basically this means that your campaigns have a better chance of success. You’re always going to have a constant stream of campaigns going out. They’ll just be shifted by Whether it’s six days or six weeks or six months for the marketing team to make their their launch happen. But it then has a list of really solid campaigns that always work and the product’s always there for them backed up with great testimonials and videos and everything they need to create to make that campaign really pop.

And then with customer teams, right? One of the really key things we have customer teams. We’re talking support, customer success, account management, customer service. They no longer have to deal with complaints when dates are missing, when dates are missed, right? Cause you’re not sitting here making promises of what’s going to be delivered and when you’re focused on solving the right problems for the business.

And things are constantly going out the door because you’re shipping faster, but. If you have a customer facing roadmap that shows a whole bunch of due dates and delivery dates, you’re beholden to either hit those dates or let somebody down, and you’re no longer going to be letting people down. You’re just going to be shipping the right things that make sense for your business and just constantly keeping your customers updated on what’s coming or what’s been launched.

yOu no longer have to field endless feature requests. It’s more focused around which problems to solve, right? So you’re still going to feature requests, but you can align them with the problem to solve and be able to give people a sense as to whether these are the types of areas that you’re focusing on or whether these are areas that aren’t congruent with your strategy.

And you’re no longer taking in customer. Requests and constantly thinking, Oh, should we build this one or should we build that one that we heard last week? You’re focused on solving problems that are important for the business. And then the roadmap itself, the now next later roadmap, as I said, with the sales team, it’s safe to share, right?

It’s easier to understand this roadmap. You can basically say, here’s where it is. We are now. Here’s where we’re going with it. And here’s the reasons why we’re trying to hit. We’re trying to solve these types of problems and build this type of company. And that helps your customers understand whether your product is aligned with their longer term vision.

So it’s not about getting their pet. feature in there. It’s about whether it solves the right types of problems for them, regardless of which feature you actually end up building to solve that problem. So you can use this opportunity to get customer validation and to get buy in on your product strategy and your vision.

You can show them the Now Next Later road map and get that buy in. And then you can iterate your road map based on insights that you glean from these customer conversations. So make use of your roadmap, get it in front of customers and use it to get your get insight as to whether you’re heading in the right direction that, that works for where the market needs you to go.

Justin in the chat had a really good point here. He said, your customers can often be more forgiving than your internal teams. So once you’re able to show people that. You are building towards a solid vision. You are solving key problems. They’re not going to get picky over which feature gets delivered.

When they’re going to worry that you’re actually still constantly building. So show them what it is that you are building and what have been building and then show them the problems that you’re solving that you’re solving for as you move forwards. So let’s really drive this home for your team.

We want to finish your, your presentation to your team here with some stats. And you want to say, let’s not be a statistic, right? We know that 75 percent of businesses anticipate that software project will fail. That whole planning things out in. Many projects lined up on your timeline roadmap.

75 percent of them aren’t going to meet the time scope or cost or quality requirements upfront anyways. So what is this whole planning thing that we’re doing anyways, it feels like a big waste of time. We also know that 32 percent of it projects face challenges because they’re, they don’t have clear objectives.

So let’s solve that by making sure that roadmap is tied back to an objective. If you can’t tie it back to an objective. Don’t put it on the roadmap. We also know that 45 percent of features and functions in software projects are never used. So let’s try to solve for that problem, make sure that we are building stuff that solves real problems and aren’t just being put on the roadmap because somebody asked for it to be on the roadmap, which frankly is how a lot of that stuff gets on your timeline roadmaps.

And we also know that 17% Of projects run the risk of failing so badly that they threaten the existence of the company. So let’s not put the business out of business. Let’s make sure that we’re focused on solving the right problems in the right order and tying our problems, our strategic steps the problems we’re trying to solve back to strategic goals for the business and not wasting any time, not risking the business by building projects so badly that it takes down the whole company.

So with that, I recommend that you wrap up. This is why we’ve got a a slide deck here for you to use. You wrap up and then ask questions, right? Get people’s feedback. Product management process, a roadmapping process is something that you can build and then you can iterate on. This is why we have things like in ProdPad the now next later columns can be renamed.

It’s not a dogmatic approach. It doesn’t say you have to put this on the roadmap in a certain way. You can use it in a very flexible way and take this feedback from your team. Figure out what works for you. If you need to do Q1, Q2, Q3 or some variation of that to get people on board, do that. But take this time to ask questions and get people on board with it.

So this Grab a screenshot of this, if you like, this is a course that you can take. We’ve written this course that outlines what a NowNextLater roadmap is, what are the benefits in a lot more detail than what we’ve covered today, and then practical steps to transition from your timeline roadmap to your NowNextLater roadmap.

So take this course and prepare yourself with. This learning so that when your team is asking questions, you’re prepared. Lesson four is all about convincing your stakeholders, right? Getting those tricky stakeholders on board. We have shared this deck with you as well. So grab a screenshot of this page too.

This deck is basically the same deck that I was just showing you a minute ago. But it has notes in this, in the Speaker section that you can use to talk your team through and get them on board. It’s completely editable, so take out the parts that don’t work for you, add in parts that you think will work for your particular context.

But this is a tool that you can use to get your team on board. Lauren’s just asked as to whether we’re going to be sharing this with the recording. Yes, absolutely. So you’re all going to get a copy of this. Feel free to share it with your teams, share it with your fellow product people, share it around, make use of it.

We want to just help people get away from timeline roadmaps and move them to NowNix later. aNd on that note, I want to invite questions. 

[00:49:44] Megan Saker: That was great, Jenna. Thank you very much. We’ve actually got a lot of 

[00:49:47] Janna Bastow: questions. All right, let’s tackle them. 

[00:49:50] Megan Saker: In fact, Ryan says it feels like we need an after party.

There’s so many questions to come in. So listen, we’ve only got five minutes. We might not get to all these questions. If we don’t, I’ll collect the questions, extract some answers from Jenna’s head and maybe include those in the email afterwards. Okay. So where shall 

[00:50:08] Janna Bastow: we start? Um, there’s so Ryan asked, do we have any good visuals that show how attempting to the team make more at the same time causes them to slow down?

I have seen something like this, so I don’t have one in this deck but I can definitely point you to something that I think might be helpful. Or if not, I can scratch it out. I’ve done it, that same sort of thing on a piece of paper before and showed it to people to make that case. So really what you’re looking for is something to.

Really nail home that point that having people work on multiple things at the same time actually makes them slower. And that is a truism, right? What often happens with the timeline roadmap is that they end up trying to tackle a whole bunch of different things and they don’t actually move faster.

And this was an interesting 

[00:50:59] Megan Saker: question, Janna. How would you respond to the claim that it won’t work for B2B software because enterprise customers require reliable time and feature based roadmaps or they won’t buy 

[00:51:11] Janna Bastow: in? So I’d actually push back on that because most of the time enterprise customers don’t require that, right?

Enterprise customers, just like any other customers, buying the product that you have today. If you’re not able to sell that product as it is today, either the product isn’t good enough, And, shouldn’t be out on the market with a big sales team trying to sell it because it’s not ready. Or you’re selling to the wrong types of customers.

Enterprise customers like to throw their weight around. They like to say, hey, we’re so big that you should go build this one thing. But what you should be doing is turning that around and saying, that’s good feedback. And we’re going to take that on board. But focus on building the thing that’s best for the wider market and is going to get you more.

Of the right types of customers, whether those are enterprise or not. So if you’ve got like a whole bunch of enterprise customers asking for the same thing, you might want to prioritize that, right? You’re moving something up in the roadmap. But each time you take a custom piece of work and you say this enterprise customer wants to buy a product, but it needs this one custom thing that no one else is ever going to use again, that is work that you’re going to spend for that month or several months building that thing that you won’t be able to spend doing.

Discovery work and experimentation led work that’s going to drive the product to the right types of customers in the future. If you’re just constantly building these custom pieces of work that don’t fit with your product roadmap, you’re going to end up with a Frankenstein of a product that can’t really be sold by to anybody and can’t be supported well either.

So it’s really important to actually think about whether these things are worth doing or not, and oftentimes teams who are in the habit of doing that aren’t spending enough time finding the right customers, that ICP were stuck in that agency trap, right? What they’re really doing is they are selling off pieces of their time in order to get small bits of cash or sometimes large bits of cash.

But they’ve got to be and I’ve got a whole talk that I can share on this, the agency trap, you’ve got to make sure that you’re not falling into this agency trap and building stuff just because someone said to jump, right? So you’ve got to find that line. 

[00:53:10] Megan Saker: Janna, we had, A couple of people wanting to know your thoughts on jobs to be done. And that’s sitting as part of the now, next, later. 

[00:53:18] Janna Bastow: Yeah, absolutely. So jobs to be done worked really well with the now, next, later. Basically it aligns with the problems to be solved, right? If you’re saying that there’s a whole bunch of customers who want to have who want to solve for this particular job and your product doesn’t do that now, then the problem to solve is well to.

Allow for people to solve that problem, to do that job. And so that becomes the placeholder on your roadmap. And within there, you might have a bunch of different experiments or things that you can do to help them get to that point to be able to solve that particular job. So jobs to be done is a really good way of thinking about things.

Cause it aligns your customer problems with your business problems. 

[00:53:57] Megan Saker: And this, we’ve got Kayla and Catherine are both experiencing the same problem. How do you set limits on what classifies as now? I have stakeholders that try to push a lot of items into the now when we simply don’t have the resources to tackle every item in the now 

[00:54:12] Janna Bastow: column.

Yeah. Everything is now, nothing is now, right? Exactly. There’s a couple of things you can do. Treat it very much like a Kanban board with work in progress limits. In ProdPad, you can see how many initiatives and how many ideas you have in each column. And if you have only one team working on stuff, you probably shouldn’t have 10 different, um, now things.

Cause are you actually working on that many right now? Or actually, are they just trying to make them look like they’re happening closer by not putting them in the next. So use that forcing function. What are you actually working on right now? What is in active discovery and active delivery? That’s keeping your team busy right now.

Everything else put into the next and prioritize in there. The other thing is trying not to go too granular. Some people break their problems into really granular, little tiny problems, and they’ll have 20 different problems. And actually, if you took a step back, take a step back, you’d realize this is one problem area, and this is another problem area, group them together and tackle them.

And, as they move into your now column, you can break them down into more detail. But try not to have. hugely granular roadmap that becomes a pain in the butt to read. Ideally, your roadmap shouldn’t be any more than what fits on a screen or two, maybe a scroll but not a big scroll. You want something that if you printed it out, it fits within a printed page or two.

So you can hand it to somebody and they can read it. You don’t want an overwhelming roadmap with all the things. It’s not a replacement for your backlog. Otherwise it doesn’t actually tell people what your strategy is.

[00:55:39] Megan Saker: We are now out of time. We still have a whole bunch of questions here that we haven’t answered.

So I think the best thing we’ll do is, like I say, I will collate them all and we will write out the answers and make sure you can all see what was asked and indeed Jenna’s reply to that. Thank you very much, Janna. That was great. Like I say we will email round both the recording and the course and the the slide deck so you can take that away and use that with your stakeholders.

So best of luck making the move to Now Next Later and do let us know how you get on and if you want any more help. 

[00:56:21] Janna Bastow: Yep, absolutely. So everybody’s looking to make this transition. Get in touch. Let us know how you get on with it. Let us know who your tricky stakeholder is, and we’ll be happy to help you through, provide any guidance on that.

We’ve probably written something for it. And as Megan said, that we are going to take your questions and make sure that we we get those answers out for you because this is a an area that is fraught with contention. So let’s help you get through it. Good luck with everything, grab that presentation, and we’ll see you on the flip side when you’ve got your NowNext later.

Good luck everyone! And bye for now.

[00:00:00] Janna Bastow: Hey, everybody, come on in. This is Saielle. She’s joining us for our webinar here today. And as you get settled in, feel free to pop open that chat that we’ve got here and say hello. Jump in the chat and let us know where you’re calling in. 

Personally, I’m here in Brighton, UK and Saielle, how about yourself? 

[00:00:19] Saielle DaSilva: I’m in London.

[00:00:21] Janna Bastow: Excellent. So we’ve got to UK massive going on here. How about everybody else? And I can see the people that are coming in here. Now. Another London. Represent. Wonderful. We’ve got anybody from further afield?

[00:00:32] Saielle DaSilva: Uruguay, Dublin, Portland, Oregon. That’s like eight full time zones. 

[00:00:37] Janna Bastow: Yeah, nice one good morning. Good morning. Somebody did ask the question here as well.

Which is, will the session be recorded? Yes, this is being recorded as we speak. 

 A little bit about this webinar before we get started.

So this is a series of webinars that we run here at ProdPad. We call them our Product Experts series because we bring in product experts to come talk to us. The past talks like this one have always been recorded and we have a mixture of firesides like today, as well as presentations from our product experts.

 We also have a focus on the content on learning and sharing. So today is going to be recorded and shared, and you are going to have a chance to ask questions. So really excited to hear your questions and see what you all think as well. 

Before we kick it off, let me just tell you a little bit about ProdPad. So this is actually a tool that was built by myself and my co-founder Simon. We were product managers ourselves, and we needed tools to do our own jobs and.

We needed something to help us do things like keep track of the experiments we were running in order to try to hit the business objectives that we were given and to solve the customer’s problems that we had and to keep tabs on all the ideas and feedback and everything that made up our backlog.

So building ProdPad gave us control and organization and transparency, and it wasn’t long before we started sharing it with the other product people around us. And today it’s used by thousands of teams around. So it’s a free tool to try. And we even have a Sandbox mode where it has example product management data. So you can see how things like lean roadmaps, OKRs, experiments and everything else all fits together in a product management space. And our team is made up of product people. It’s founded by product people, and it’s made up of product people. So start a trial today, start using it and then get in touch and let us know your feedback.

We’d love to hear from you.

Now let’s get onto the main event. So we’re joined here by Saielle DaSilva, and I actually met sail originally at a ProductTank years ago. It was right after Saielle, had first moved to London some years ago and we’ve stayed in touch to. And Saielle, she’s worked for companies big and small from everything from network infrastructure to IOT and machine learning, working for companies like AT&T, Amazon, Pivotal. She advocates for diversity in tech organizations and helps companies apply user centered design to internal processes.

She’s currently a product leader and director of UX at Cazoo. And she recently grew her UX team to 60 folks. And that hyperscaling came with a lot of challenges, including how to scale, where to let go and how to know where letting go was the right thing to do. So as a product leader who has been there and done that, she’s definitely the right person to speak to about how to get out of the weeds as a product leader.

I think it’s something we don’t talk about. Everybody say hello to Saielle! 

Before we get started. Could you tell us more about your career and your work at Cazoo? Like how did you get to where you are today? 

[00:03:37] Saielle DaSilva: Yeah, that’s a good question. So my first UX job actually I kind of hacked it together.

I was working at an ad agency in automotive, so I’ve kind of come full circle. But what happened is I was working on an email and it basically had like just a ton of links. And I was like, there’s gotta be a better way to do this. And we were basically shipping micro-sites and email, and I was like, this just feels really inefficient and stupid.

And I made a bet with my boss and I was like, okay, I’m going to design a better way for us to do email. And I’ll make you a bet that my email will outperform your email. And if I win, I want you to give credence to this like UX thing that I’ve been researching. And if you win, I’ll leave it alone, and we’ll just go back to business as usual. Yeah, my email outperformed theirs by like 400%. And I’m like maybe a month and a half later, my boss was like, okay, this UX thing that you’ve been like, suggesting that we do, it seems like you’re really good at it. Do you want to kind of do that full time?

And so from there, I was in charge of the front end team and taking on new challenges, understanding usability and improving user experience across everything that the ad agency did. From there to make a very long story short, I worked for a couple of places. I worked full-time at AT&T and freelanced for Amazon.

And then I went to work for Pivotal Labs, helping them set up a brand new office in Dallas. And basically growing the design practice. And I worked alongside Emily Tate, who is now Managing Director for Mind the Product. And who’s still one of my really good friends. And after that, I moved to London, I worked for a small startup that had hopes of scaling and I wasn’t crazy about it.

So I ended up picking up the job at Cazoo where I’ve worked, as you said, growing the team from literally me and my first hire, who was a researcher, all the way to 60 folks. 

[00:05:56] Janna Bastow: That’s amazing. I love that it was all based on kicking off with a bet, you know, just proving that this thing that you do is actually worthwhile and you won the bet!

There’s so much hanging on these these hairpin moments where it could’ve gone either way, but if you were backing it with the knowledge that you had about UX, even if it was a gut feel, but it’s based in the research that you had, then it was a good bet. And sometimes that is the way that you move up in the world is you call BS and say this isn’t right. I think there’s a better way to do it. And give me a little bit of space to show that I can improve this a little bit. And you were fortunate that somebody did give you that space and then gave you that chance to flex more of that UX muscle. 

[00:06:40] Saielle DaSilva: So that old boss and I are still really good friends and he currently works for Amazon.

And so, Hi Dave!

[00:06:49] Janna Bastow: That’s amazing. Excellent. And you mentioned working with Emily Tate as well. We did a webinar with Emily Tate just last month. Did a great Product Experts webinar. She was talking about embracing agility in organizations that are built for predictability.

[00:07:06] Saielle DaSilva: That sounds like a really fun topic. 

[00:07:10] Janna Bastow: It was, well, you can go back and watch it. Like all of the other ones that we do, we record these because I know that product people are so busy. Right. I mean, that’s one of the fundamental problems that we have. 

[00:07:21] Saielle DaSilva: Yeah. 

[00:07:22] Janna Bastow: Wonderful. Well, thanks so much for joining us here today.

Now, we’re talking about getting out of the weeds as a product leader, then why is it important to get out of the weeds? What’s at stake? Why not just get your fingers in all the pies? 

[00:07:37] Saielle DaSilva: That’s a good question. Well, one you’ve only got 10 fingers and if you’re sticking them in other people’s pies, you’re probably transmitting COVID.

So don’t do that. Clean your fucking hands, please. And thank you. But long story short, one of the reasons that you can’t be in everything all at once is: 1) it’s just not scalable 2) you’re just going to burn yourself out and you’re going to limit the opportunities that your team has to really contribute and grow themselves. And, to me, the best leaders create the conditions of clarity for other people to grow too. You might hear that called servant leadership or any other number of labels. I think the label is a lot less important than the behavior. And that behavior is really about making room for other people to support and help you and being humble enough to know that you can’t do everything.

And so one of the things that I’ve tried to do very consciously is know where my impact was worth the most in terms of like what our team is working on, because you know, you’re the CEO, you know, that like not everything that feels urgent is important and you have to prioritize where to put your attention to make maximum impact.

And that’s something that every leader has to do is know like, okay, there’s, you know, there’s a lot of different things going on, but where can I spend my time and get the most value out of things. Also, I love that Keji is using the chat and Rhonda y’all feel free to like hop in and like drop some comments.

It’s not going to bother me at all. I have ADHD. So if you stimulate me, by like chatting in the right hand side, like great, we can, we can just vibe. 

[00:09:24] Janna Bastow: Excellent. I love this crew who joins. And yeah, by all means everybody jumping on the chats and have fun with this. Keji says challenge accepted.

Wonderful. And so you were talking about this this concept of, you know, understanding where your impact is, how do you begin. Finding that, how do you begin understanding that and measuring that and, figuring out whether you’re in the right spaces or not. 

[00:09:51] Saielle DaSilva: Yeah. I think one of the ways that I kind of do a sense check on this from time to time is, do I have clarity about what the most important thing I’m working on is, and that’s just a good barometer of where am I spending my time? And am I getting impact from my time? And if ever, I feel like the answer to that question is no. Like, no, I don’t have a clear sense of what the most important thing I’m doing is I either check in with my boss or I do a dump and sort, and I go, okay, what are all the things that I’m working on?

And then how do I like either delegate, de-prioritize or like just move on, right? Like you can only do so much. And so thinking about, okay, what are we working towards as a team? How do I, you know, if it’s important, is there somebody I can give it to? And if it’s not important, can I like just be prioritize it and sense check with somebody that like, Hey, you asked me for, this is it’s still the most important thing we could be doing.

Right. And so communication is actually a really big part of getting out of the weeds. And then, as you start to look for that impact. I think the other thing is like check in with you know, if you’re the most senior product person check in with your exec team. If you’re working as a product manager, day-to-day, check in with your boss, check in with the stakeholders that you work with, right.

About like, Hey, what’s the most important thing we could be doing right now if we had to drop everything, but one thing, what would that be? And, you know, if the answer is something different to what you’re working on, why. 

[00:11:32] Janna Bastow: Yeah, absolutely. Absolutely. And I think that’s really key is being able to ask that question of yourself and others.

Is this the most important thing for you to be working on? I think a lot of people make a decision on what to work on and then just blindly work towards it and don’t have the guts or the space to they don’t give themselves the permission to say, actually, I thought this was the right thing to work on when I started the quarter or I started the month or I started this goals list and turns out it’s not.

Things have changed and you know what, I’m going to throw this out because it’s no longer the most important thing for me. You know, just like priorities overall for the business change our PRI our individual priorities. So it should be flexible as well. 

[00:12:12] Saielle DaSilva: Absolutely. I think agility—we tend to treat agile as responding to change in terms of the roadmap or the backlog. And we don’t necessarily apply that to ourselves or the behaviors that we engage in. And to me, because I have a design background, the behaviors that we engage in are basically just the same thing as the product decisions that we’re making, because the actions that we choose every single day, are decisions that we’re taking to work towards or not towards something, right. So if I choose to like maximize my impact, whatever that might look like in my role, I have to ask the hard questions about when’s the last time I got feedback on this, or since checked, whether I’m still working on the most important thing. And then, you know, the next question that inevitably follows is: who needs an opportunity to shine. And that’s one of the other things, when you have a team it’s like, who needs an opportunity to like stretch their wings, who’s ready for some growth. 

[00:13:12] Janna Bastow: That makes a lot of sense. Delegation itself is such a tricky art and sadly, it’s not really something that we’re ever taught.

You know, we’re taught to do our work. It’s been drilled into us that it’s something that we have to go and complete, not to hand off to others. We’re not really taught this art of how to take work and package it up for other people. And yet it’s something that is hugely needed to be an effective leader.

So like, why is delegation tricky first? 

[00:13:45] Saielle DaSilva: I think when you first start delegating and learning to delegate things, one, you’re definitely attached to the work and you’re like, oh, but I know exactly how to do this. And it’s like, I could spend just a half hour doing it. And if I do it myself, I will do it in a half hour.

Again, the challenge to yourself as a leader is going, okay, I can do it in a half hour, but then nobody else gets the opportunity to learn or grow or get feedback or try something new. And then two it’s like, okay, that maybe worked. And I know how to do it for my last company. Assuming that you’re like, you know, mid-weight or further in your career, like maybe it worked at your last company.

Maybe the environment is different. Maybe the situation that you’re working in is different. Okay. Even though what you do could work right off the bat. Like it’s better to give other people a chance to try to solve that problem. And so the other part of delegating, I think, is really hard at first is people tend to delegate the solution that they’re trying to build rather than the problem they’re trying to solve.

And so when I first started managing other designers, I would say, okay, do this, this, this and that. And that is just such an anti-pattern of how to delegate because you’re not making any room for the other person’s creativity and that problem solving. And really what you want to do is communicate. Look, the problem that I’m trying to solve is blah, blah, blah.

I have an idea that might be this, but that’s just input, not direction. You figure it out. And so I make that distinction and that’s one of my. Personal life hacks for delegating effectively is this is input, not direction or asking like a leader that I work with or report to like, okay, would you consider that input or direction?

Right. Cause like the other thing is like, people will be delegating to you all the time too. Right? So delegation’s a two-way street and paying attention to the way other people delegate to you can give you a sense of what works for you and what doesn’t. So the other side of that is going okay. And just asking like active listening questions, like, is this input or direction, right.

Somebody has an opinion. I work with our CTO a lot, his name’s John. And when John has opinions about things, he’ll go, this is literally my uninformed opinion. Do what you think is best, but here’s my opinion. Please consider this input not direction. And so we’ve learned to build that vocabulary into the way that we negotiate ideas and try to get to outcomes that we’re working towards so that we can have a really clear sense of, okay, does it need to look exactly like this or would something generally in the ballpark still work as long as like, you know, it might be different, but it still gets you there. 

[00:16:27] Janna Bastow: Nice. I really like that. Those were some really good tips. Do you have any other tips on how to become a pro at delegating? 

[00:16:35] Saielle DaSilva: Yeah. I mean, my, my team hates it, but like, they also love it.

You know, they love to hate it because you know, basically whenever somebody observes a problem that they want fixed and they’re like, oh, maybe we should, blah, blah, blah. I don’t know. Like let’s say it’s fix the coffee. Like we don’t like the coffee in the office. I’m like, Hey, you know what?

That sounds like a great idea. Why don’t you figure out who to talk to about that and go make that happen? And it could be, oh, should we, I don’t know, research the blah, blah, blah, for this feature. Yeah, we should. Congratulations. You get to do that. And it drives them a little crazy, but at the same time, they know that we have an opportunity based culture. Right. And so if you come up with ideas, you will be supported. You know, it’s not that you can’t have any support to go do it. It’s not, okay, go do that, and like, please don’t ask me any questions and leave me alone, and I’m too busy for you. There’s an opportunity to go do that. If you have questions, please come ask me.

But otherwise, like I’m ready to just take your idea and see, what’s see what’s up. You know, if he wants some input, you can ask your peers, you can ask your manager, you can ask me, but somebody will be willing to help you. But it sounds like you’ve got some ideas and some passion about this. Why don’t you put something together?

You know, if it’s really important and I’m like maybe we should like sense check that first. I’m just like, why don’t you put some ideas together on paper and give me like five to seven bullet points max, when we can check it out at the end of the day. And so what that does is it lets me critique their thinking early so that by the time they get to building a solution or approaching a solution, whatever it may be, it’s already kind of like vetted for 1) the problem we’re trying to solve and 2) how we should think about solving it. Right. And so another thing that I’m doing all the time is just giving a shit ton of design principles away. So, Hey, maybe choose clarity even over speed when it comes to communication, you know, and like even overstatements are a great way to make like ad hoc principles that can help you shape your team.

And this applies kind of at all levels of delegation, right? If you’re working as a product manager, You can start to negotiate with your engineers about like the product features later, working on, you know, for ProdPad you might choose you know, accessibility, even over speed of implementation.

Right? And you might say accessibility is so important to us that we are going to choose it even over speed. And when you have that discussion with your engineers, guess what the people that you work with will start to echo those things back to you and use that. As a decision-making framework. Right. And so absolutely catchy.

It’s like, it’s really good as a way to lean into the work that you’re doing and thinking about, and it’s a way to broadcast your values, right? The most important thing, I think when delegating is make sure people understand the values that you think with over almost everything else. 

[00:19:49] Janna Bastow: That makes a lot of sense.

I really love how you framed that because what you’re doing is giving them the values, the framework, the understanding as to the way that you go about solving problems. You give them space to speak up. If they speak, see a problem and then you give them guidance on how to go about solving them. I think that’s really key thing is not to make it feel as if they spot something they’re now responsible for going to fix it. Like, oh God, I mentioned the coffee problem. Now I have to go source new coffee. Oh, wow. I’m not going to mention the next thing, but if you can guide them through and say, here’s how you can take it to the next step.

Give me those five to seven bullet points and I’ll help critique it. And, we can help figure out what I 

[00:20:27] Saielle DaSilva: figure out the right audience for it. And if you need a meeting, who that meeting should be with and all that other stuff, 

[00:20:34] Janna Bastow: Yeah, there’s a lot of nuances in there because you’re dealing with people and their their ideas, right?

People come to you with suggestions and thoughts about how they might want to improve things. And it’s really important to hear them out. But at the same time, not make it feel as if they have created work for themselves or created work for others by mentioning things. But if you provide them with a good framework for it, then it can make a big difference.

Now Andrew and the QA has asked a really good question here. You said, how would you suggest providing supportive feedback when delegation routinely results in poor results or delayed delivery? 

[00:21:12] Saielle DaSilva: Okay. So that’s a really good question, Andrew. I think it depends on your level of involvement with the person.

And the first question I would ask is, did they misunderstand the outcome that we were working towards? Did they misunderstand the goals? Did they misunderstand the timelines? You know, were the timelines unrealistic? There’s all sorts of nuance there and ultimately to use the standard product managers strapline, it depends.

But if you don’t say that at least once in a product management chat of any kind, like you’re probably doing it wrong. Right. So providing supportive feedback, retrospectives are a great tool and it doesn’t matter what you’re delegating or what’s being done. It’s really important to make sure that people have retrospectives, right.

Is this a team problem or a person problem, right. Is another great sort of like first line of inquiry. And I think if you start to identify, you know, for the sake of argument, if you start to identify that it’s not a team problem, it’s a person problem. You know, Then, cause the question leans into supportive feedback.

So it’s probably a personal issue. So 1) does the person understand what they’re being delegated and what they’re working towards 2) am I as a leader setting clear expectations, 3) does the team have the room to challenge, you know, the delivery timelines and the implementation approach that has been recommended or suggested like, what is the two-way feedback there, right?

Because if the results are poor, like, are you as a leader, close enough to the work to prevent that outcome from happening? You know, are you getting the right level of visibility earlier in the process? Because if you’re routinely ending up in a place where you get poor results, like my question to you.

What could you do to get involved earlier? You want to be supportive, but sometimes that means being in the trenches with somebody. And one of the things I picked up working at Pivotal was an “I do, We do, You do” model. So “I do”, I do something and you watch. “We do”, we do something together based on you having seen me do it once or twice or a couple of times.

Right. And then “You do”, you do, and I watch. And that doesn’t necessarily need to be you. If you’re already strapped for time, there are probably other people in your team who can do that for you. Depending on the size of your team. Right? So, and that’s something that if you teach somebody and you go and you set expectations and you go look, I’m going to do this once or twice with you just to kind of teach you a little bit about how I’m thinking about this.

If I’m solving this problem, you know, whether it’s roadmapping or story writing or backlog management or prioritization, whatever those things are, right? Whatever the ins and outs of day-to-day work are. And then the other thing is supportive feedback. Hey, it looks like we missed the mark on that thing that we were trying to work on.

And we also missed not just quality, but time. Let’s talk a little bit about it. How do you think it went? What could we do differently and see where that person’s self-awareness is as a starting point, right? If the person’s like, well, it was fine. You know, it’s fine. And there’s no room for critique there.

Then that’s a personnel issue. If they’re admitting the mistakes, they might know where some of the blockers are that you can’t see. And I think it’s really important to understand that, as a leader, you inevitably have limited context. So you have to be a little bit curious and just kind of put your Sherlock Holmes hat on and lean into what other people may or may not be experiencing day to day to really understand the situation.

[00:25:11] Janna Bastow: Excellent. And yeah, Andrew said that he really appreciates that response. And like, Andrew, I really liked the I do, We do, You do method. What I like about that is that it highlights where the problems might be like, as you pointed out, it could be with the way that it’s being communicated.

So you might identify it. The I Do area that you actually don’t know how to do this thing when you do it, it actually results in poor quality because you didn’t realize how hard the thing is that you were trying to delegate. You know, it’s easy to say, yeah, go write a thing about this or go build a thing that looks like this, or design a thing that looks like that.

But in reality, when you go to try to do it, you know, This was actually a lot harder and I didn’t communicate this well. At the, we do, it might be pointing out issues with communicating how it’s actually done and at the You do, it might catch things like whether they’ve misunderstood something or whether they’re actually not particularly good at a particular task.

At which point you can identify that and start to work on those particular areas. I love that. That’s great advice. Thanks. So, there’s a fine line between challenging people so that they can grow and learn and challenging them so much that they fail. Can you delegate too much? How do you know when you found that right balance?

[00:26:25] Saielle DaSilva: You can definitely delegate too much. And as we’ve been growing our Munich office, like I have noticed that I have over delegated a little bit and had to get involved again, to make sure that people had clarity and support, like where we’re currently working on internationalizing.

So we’re launching a couple of new markets. And that whole like translation management process has been really heavy. And one of the folks in my team was really struggling with getting some clarity about what level of ownership they should have. And there was a little bit of chaos. And so I had to come in, set some boundaries, and kind of realign folks. And it wasn’t anything that this person was doing wrong. I think really the challenge there was the expectations from their stakeholders was that this person would literally solve everything. And so they were taking that on themselves and actually, I got involved to tell the person that I had delegated to, please delegate more. And actually, let me help you with that. By getting some of the folks who had been basically expecting you to do this, to take more ownership and put more skin in the game. Cause actually they shouldn’t be asking you for this. They should be asking themselves. And they have the tools that they need.

This thing is at this stage in the process, it’s on them to take it from there and make sure that it makes it through, into production and to the end in the right way. So again, looking at that person, I got some feedback that there was concern, like, oh, maybe we’re not, going to hit our deadlines and get it right.

And I was like, okay, I’m gonna ask some questions and take a look. And it turns out that the person that was that I delegated to was just taking on too much themselves and actually just needed to themselves delegate more and distribute the load. And so I was able to do that and we’re in a pretty good place now.

And that was like within the last couple of weeks. 

[00:28:28] Janna Bastow: Awesome. That’s great. Congrats. And it’s great that you’re bringing these real world challenges and experiences here. How do you make room for people to take on challenges? If you have somebody who doesn’t want to take on challenges and doesn’t want to push themselves, how do you encourage them to take that step up?

[00:28:47] Saielle DaSilva: Well, the first thing is we look for people who do want to take on challenges in the hiring process. But if you find somebody who’s content and not really pushing themselves or growing a whole lot. One thing is I look for adjacent opportunities. So like, what’s the next biggest container you could reasonably be operating in.

So I wouldn’t take somebody who’s brand new to the team, and go, Here, drive some strategy for us for the next year and a half. Right. But I would go, okay, you’re still working on your technical skills. Is there a course or something, you know, I basically ask myself who’s, who’s kind of coasting or.

You know, and it feels a little bit like being a stark and there’s like blood in the water a little bit. Right? Like who’s got a cut. But, but it is a little bit like hunting and I know that that’s a really shitty metaphor, but like, it is a little bit like just paying attention and being mindful of the team, you know?

Or to use the greenhouse metaphor, which plants in here are ready to bloom. And so who needs a little bit of water, a little bit of soil, maybe a little bit more sunlight to get to the place where they have the support that they need and are really thriving and throwing down roots at that next level.

Right. And so paying attention to that, like I actually had a conversation about somebody in our team today, who I was like, this person seems a little quiet what’s going on there. Are they ready for some new opportunities? Should we be looking at some of the opportunities that are coming up next year?

Should we be considering them for a slightly bigger role? And so. Yes. And you know, the other thing is I talked to the person and so I had a chat with this person who I was like, you know, and I didn’t like go for the jugular on it. I was just like really casual. And it was like, Hey, let’s talk about what’s going on in your team.

What are you feeling? About the level of work that you’re operating at? And they were like, honestly, I’m like a little stressed because I feel like I should be doing more, but I don’t know what to be doing. And I was like, cool, let’s talk about that. Right. So like, most people will highlight that they are eager and ready to take on new challenges. And if you have somebody who’s like, not quite there, maybe it’s a personal life thing. Right. But being a caring and attentive manager can help you prioritize where that person’s at, because we all have ebb and flow in our lives.

Sometimes people need to work to just be a little bit consistent and if you really need something out of that person, cool. But growth for its own sake, isn’t always the healthiest thing to do, especially if somebody has a lot going on personally. So just make sure that you’re balancing.

[00:31:25] Janna Bastow: Yeah, that makes a lot of sense. I really love the gardening metaphor and also the blood one. That’s good too. There’s been a couple of questions that have come in here. Gareth has asked how do you determine whether a task is challenging for your team and you should just give them space and support, or is it something that you should do yourself?

[00:31:47] Saielle DaSilva: I would rather default to letting the team take a stab at things more often than not. There are pros and cons of that method, but I tend to choose to go, you know what? This is probably challenging enough. Here’s something for me to like, could I do it? Yeah. Do what I need to do it with several of you.

Yeah. In that case, it’s a team thing like here, one of you take this on and here’s the problem you’re trying to solve. The thing is as I try to be really concise and really clear. So I try to force myself to argue things and set them up in five to seven bullet points so that people know what’s the most important thing.

Right. And so I will say, Hey, we’re trying to do some research on international expansion in a new market. What we need to understand is these particular behaviors. And I always pick at least like one anti-pattern or one constraint to impose as a way to frame how much work I’m expecting.

Right. So it can be something like, hey, we should probably do some research on this. And I would expect that we don’t spend more than like a couple of days on it because it’s just to solve these questions. Right. These are the questions that we’re trying to make informed decisions on, or you know, when it comes to things that are a little bit closer to product strategy, Hey, I want you to take a look at, I don’t know, maybe like the roadmap for your particular subset of the product.

And let’s make sure that we’re making informed decisions. When’s the last time we did some user research, you know, when’s the last time that we looked at the priorities in the roadmap against the user research needs that we have. When’s the last time that we paid down some tech debt so that we can do cooler stuff in the future.

Right. And so those sorts of questions kind of open up room for discussion. It’s my personal style to force myself to delegate a lot more and just check in frequently. Right? And by checking frequently, I go, I am here. I’m going to ask questions about this and probably in a week or two, if you want me sooner than that, you can certainly ask questions.

Please, don’t get stuck in a rabbit hole, but if you don’t want any input, like I’ll see you in two weeks. And so setting some expectations around when you’re going to check in and letting people know that you’re available is another great way to make sure that something challenging doesn’t go unsupported.

[00:34:11] Janna Bastow: Yeah, that makes a lot of sense. And it sounds like there’s a lot of work here. How big of a team can somebody manage in this sort of way? What’s a reasonable team size 

[00:34:21] Saielle DaSilva: Less than the number of managing right now, 13 direct reports right now. And that’s way too many.

But I ideally like six, seven. Something like that. Right. And if your team is bigger than that, you have to choose where you pay attention. Because you can’t do everything for everyone. All the time. 

[00:34:44] Janna Bastow: Yeah, that’s absolutely true. Just fitting in things like having one-on-ones with everybody and being able to spend the time to understand, who’s struggling with what and where they are with things. It’s all great if they are all flourishing and doing great with things, but if one or two people start struggling, it’s really important to be able to be there.

Justin asked a question as well. This is related to the fact that we’ve been in this remote working state. Have you found teams are more in the weeds over the last 20 months, especially with remote working or is it more than just virtual meeting overload?

[00:35:25] Saielle DaSilva: Yeah, I think at all levels what tends to happen is you show up for a meeting, you talk about the topic and then you leave and what that ends up doing, is it kind of like, it makes that social connection very, very thin. And you don’t have room for serendipity or just chatting because people are nervous and anxious and like, rightly dealing with being isolated, working from home. It’s a very steep learning curve. And so teams do tend to be more in the weeds I’ve found.

And actually I attended standup with one of our teams today. And again I’m just diving around and like humming birding all over the organization. So today I went to stand up and one thing I noticed is like, this team was just talking about coffee this morning, before standup, they just took a few minutes and they were just talking about coffee versus tea as just a social icebreaker.

Right. And so there’s a question of the day at their stand-up and they kind of get everyone to just say something before they get into talking about work. And so standup’s a little bit longer, but you get that social cohesion that you wouldn’t otherwise have, if all you’re doing is just reporting on like what you did yesterday and what you’re doing today.

And then they end stand up with the joke of the day. There’s always like some sort of funny dad joke or pun or something everyone gets to laugh at, and then you, and stand up on like a little bit of a high note. And so that was really cute and I really liked it. And so that’s something that maybe will work in your team.

[00:37:01] Janna Bastow: Excellent. Does somebody have to like think of the joke every day or there’s a little pool of jokes somewhere? 

[00:37:07] Saielle DaSilva: There’s probably a pool of jobs. I should ask them how it works, but like maybe it’s, whoever is leading standup that day. Just the joke of the day at the end or something. 

[00:37:17] Janna Bastow: Yeah. Ah, that’s great.

And yeah, I totally agree. You know, having those little moments of social cohesion before and after, just being able to ask, how people’s weekends were and that sort of thing can make a big difference. 

You said something recently that I really loved: this concept of focusing on clarity over control in your leadership style. What do you mean by that? 

[00:37:41] Saielle DaSilva: So I try to get really clear about the most important things with everyone that I work with. Right. So today I was chatting with somebody and they were in a meeting and I was like, Hey, it it just struck me that you left about halfway through this meeting.

What did you go to? And they told me what they were up to and I was like, okay. Interesting. I think the most important thing for you to be spending your time on is actually hanging out with the people that were in this meeting, because that’s where your strategic input is. And so it was really a gentle way of creating clarity about where this person should be spending their time.

Right. And it’s not control, it’s not. You should do exactly these things. It’s not here are the ideas that you should be implementing. It’s more of a, Hey, where are you spending your time? What are you thinking about when it comes to the problems that you’re solving? And how can I help clarify anything that is ambiguous there?

And the other thing is, again, and I’ve talked about this throughout this whole chat, but like making your values and your decision-making frameworks, really clear, making your priorities really clear and then setting people up for success by making sure that they have the right support.

If they’re taking on new challenges. And so where some people try to delegate solutions. I try to delegate the problem and go, this is the problem that we need solved. And so I love my research team because they—currently, they report to me, so I’m like the chaotic, like, kid in the candy store, who’s like, we should do research on all the things. And then I’m like, oh, there’s like seven of you, which is actually a pretty big research team, but I’m spoiled. And I like my research team. Anyways, 

[00:39:29] Janna Bastow: You said all the things right. By all the things, you meant, all the things!

[00:39:33] Saielle DaSilva: Like most, most of the research, like most of the things.

So, you know, inevitably they’re like, okay, what are you trying to solve here? And like, I love that we have that dialogue because it’s something that I’ve taught them. And now they bring them back to me when I forget, right. Or when I’m like juggling a bunch of different things. And so it creates the clarity about what’s important.

And so I love that my research team will ask me, okay, you’ve made this ad hoc request. Is this the most important thing? Because I’m working on A, B and C. Is that really like more important than A, B and C, because if it is, I will drop it, but you need to create the room and the coverage and the runway for me to go do that and drop these other things and help me like communicate to my stakeholders that I won’t be delivering the things that they want at the times that they want.

And so it forces a good amount of clarity and like communication. And the other thing is we challenge each other all the time. So like that very like functional, challenging in that way means that there’s a lot of trust between us because we can have open and honest conversations about priorities and about the work that we’re trying to do.

And so when it comes to delegating, you know, it’s really important to, to set people up by making sure that they understand the problem that you’re trying to solve. And, I try to paint a picture of what would success or awesome look like, right. So, a picture of clarity for some of the research that we’ve been doing, you know, I got, Hey, we need to research blah, blah, blah, whatever it is.

And they go cool. What would awesome look like? Or what are we trying to accomplish with this? And so I come up with like a list of decisions that they could inform if we had that research. Right. So, oh, well we want to know if we should prioritize launching with this feature or that feature, or if there’s any constraints that we’re unaware of or, you know, should we be setting expectations differently in terms of the timelines that we think we’re working towards, because we need more time to learn the things or whatever. Right. And so I try to give my team a little bit of pre-work in terms of these are the decisions that we would be able to make, and this is research, right. But you can do this with product managers as well. Right. If you have a process for pitching ideas, you can always get people to think about what that pitch should or could be and make sure that they’re answering some of those questions about what decisions would we need to make to get there. Right. 

Or, if they’re trying to pay down tech debt, for example, right. Hey, it looks like we’ve got a lot of tech debt. I want you to figure out which tech debt is the most important. It would be really great if, Our hypothesis is that in a year and a half, we’d really like to be thinking about like, expanding this strategic, whatever, right? Like increasing maybe revenue per customer, to do that, we know that we’d probably need to change, I don’t know, the order management system or the way that we do billing or whatever it is. Right. And so if you, as a leader, can paint that broad constraint, it means that the team then is free to play in the clarity that you’ve created for them.

Right, here are the boundaries of the playground. Knock yourself out. 

[00:42:53] Janna Bastow: Yeah, I like that. 

I like that. And so how do you know if you’re doing a good job with delegating and providing this clarity and direction to your team? Like, how do you go about getting feedback as a manager?

[00:43:07] Saielle DaSilva: Ooh, fun one. I just ask, I have ADHD and I just ask very directly, how am I doing?

But not just, how am I doing, which is like, so open-ended that you might not get anything useful. What did you think of that? Do you feel supported? How could I support you better or differently this week? What else would you like me to. What would have made that twice as good. Was that clear? How else could I have made that clearer?

How do you feel about the way this project went? What do you think could have happened differently? What caused that? What else would you say? Is there anything else? Okay. What would you do differently? If we had to take it from the top? What decisions would you like to have made. 

[00:44:02] Janna Bastow: I like that. 

[00:44:03] Saielle DaSilva: Those are all like, really good examples of ways that—sorry. I have my, I have my user research hat and then I build scripts for myself of things that I can ask. Cause I’m actually really bad at thinking on the spot. So I do a lot of pre-thinking and so I have these scripts in my head of things that I can ask people about work, that’s ongoing, to try to check in on things and make sure that they feel supported and successful. 

[00:44:31] Janna Bastow: Yeah, absolutely. To echo what Rhonda has just said in the chat: I think those are really, really good examples, really good concrete examples. And it’s a little bit like a bit of a retro on your leadership style.

You know, being able to get this direct feedback and, it’s only by asking these questions, will you find out if it hasn’t been going well, if you haven’t been clear and I think this is really fundamentally true of so many of these skills that we’re expected to have. We’re not often trained in these things.

They don’t come naturally. They’re the type of thing that come after practice. And the reality is that your first delegation tasks, your first managerial posts, your first chances as a leader, you’re going to make mistakes. We all have, we’ve all been there. But the only way that you can improve on them is by asking these.

Tough questions that sometimes will reflect badly on your own style. But it’s by asking them and being open to the feedback yourself that you can actually improve on them and go, oh, okay. So I could have been clearer here. Well, next time, this is where I’m going to improve on it. And this is the type of stuff that builds leaders.

Leaders aren’t just born and are naturally awesome at it. They have bad one-on-ones they have bad sessions, they have bad experiences, but they do get better at it with these types of processes. And I really liked this really concrete examples. Thank you for sharing those. 

[00:45:50] Saielle DaSilva: Yeah, absolutely. The thing is, is like ultimately it’s to me designing like better feedback is the same as designing a product.

Like essentially you need to get to a series of decisions and all you need to do is work backwards from that. So what is the outcome that I’m trying to work towards? Good leadership. How would I know that I have good leadership? Well, I would check in with the people who are customers, if you will, of that leadership, at all levels.

Right? So my manager you know, if you’re the CEO, my shareholders or my customers. If you’re a product manager, maybe you’re a director of product. If you’re a manager or direct reports, as well as the stakeholders that depend on you. And just from time to time, going, Hey, how’s it going? Is there anything that I could be doing better or differently?

What would have made, you know, I love asking and I got this from Julie Zhou. What would have made that twice as good or that might be the Radical Candor 

[00:46:55] Janna Bastow: Kim Scott 

[00:46:56] Saielle DaSilva: Kim Scott. It’s one of those two it’s either Julie Zhou or Kim Scott, but what would have made that twice as good is a really good, safe question that lets people give you their ideas and input, right?

And again, feedback is input, not always and not often direction. Right? So like you can take it and think about how it applies. 

[00:47:20] Janna Bastow: Yep. Perfect. All right. Those are a really, really helpful tips and examples. You know, I think what you’ve said there, it really goes to show that everything we’ve been learning in product, everything we’re good at as product people are the exact same skills that are gonna help us scale up as product leaders.

So I think it’s really important to learn this stuff from a product leader who’s been there and done that.

On that note, I want to say thank you so much to Saielle for joining us here today. It’s been wonderful having you, learned so much.

I think this has been really helpful and I really love the concrete examples and the experience that you’ve pulled on to show us, not just how you got there, but you know what you’ve learned along the way and how we could apply the same things as we move up and learn to delegate and improve our own leadership paths.

[00:48:09] Saielle DaSilva: Absolutely. Thanks so much. If you want to keep chatting, follow me on Twitter. 

[00:48:14] Janna Bastow: Excellent. Yes. Follow Saielle on Twitter. She’s amazing on Twitter. She’s @intentionaut, definitely highly recommended. 

But thank you so much. Echoing what everyone’s saying in chat here. This has been brilliant. Thanks so much for joining today. 

[00:48:27] Saielle DaSilva: Thank you.

Watch more of our Product Expert webinars