Creating great products isn't just about product managers and their day -to -day interactions with developers.
It's about how an organization supports products as a whole.
The systems, the processes, and cultures in place that help companies deliver value to their customers.
With the help of some boundary -pushing guests and inspiration from your most pressing product questions, we'll dive into this system from every angle and help you think like a great product leader.
This is the Product Thinking Podcast.
Here's your host, Melissa Perry.
Hello, and welcome to the Product Thinking Podcast.
Joining us today is Atif Rafiq, CEO and co -founder of Ritual and a pioneering figure in integrating AI with workflow management.
Atif has held transformative roles at leading companies including McDonald's, Volvo, and MGM Resorts.
His recent book, Decision Sprint, introduces groundbreaking methods for innovating into the unknown.
We'll be talking about how to leverage technology to enhance team -based problem -solving and decision -making processes, and how organizations who are transforming to better product management ways of working can use these techniques to help scale product value.
But before we talk to Atif, it's time for dear Melissa.
So this is a segment of the show where you can ask me any of your burning product management questions, and I answer them every single week.
Go to DearMelissa .com and let me know what you're thinking about.
Let's see this week's question.
Dear Melissa, I'd love to hear your take on the relationship between product ops and a platform product manager.
The nature of the product, a platform, as an enabler of shared value across multiple internal users and teams makes it feel closer in practice to the product ops role.
How would you think about this?
So I do like thinking about product ops as a platform for product management.
I think that's a great analogy because platforms do enable us to scale the value of our systems to different applications.
It allows us to avoid duplication.
It streamlines a lot of our ways of working.
It also allows us to harness data and do more valuable things with that data, especially putting, you know, AI in there or leveraging it across systems so it's not silent.
So I love platforms.
I think they're fantastic.
And if we do product ops, great.
We should be doing that in product management as well, right?
We want to be collecting our data, using it in more powerful ways to make decisions.
We also want to be enabling the teams to be able to get their work done.
I don't know if these two things should be the same, though.
It's not like product ops should be part of the platform team because I do see the platform team directly tying to the value of the product that you deliver.
So you want to make sure that you're prioritizing the roadmap for software when it comes to the platform so that you can enhance the commercial viability of the applications you're putting on top of it.
Or you've got an external platform.
You're building it directly, selling it to customers.
That's the thing, too.
This is really tied back to delivering value to the organization, to your customers, and directly resulting in increased ARR and cost.
So that's all tied back together.
When we look at product ops, if you think of it as a platform for product management, we're going to be enhancing the way that we do product management.
So while I do think the mentality of thinking of product ops as a platform for product managers is great, your platform internally, even though your customers are your developers, you're going to be delivering direct value to those end users at the end of the day through the applications that you're
servicing. Now, you can make a case and say that product ops can directly impact ARR and our costs by making decision making faster, making us able to refine product strategy, make sure that we're making the right decisions around product strategy, making sure that we're monitoring it well, and that we
all work well together to get things out the door.
All of that will have a direct impact on ARR as well, but your end user at the end of the day is not quite your customer when it comes to your internal processes, I believe.
So while I do like the mentality between these two things, a lot of times in product ops, we're going to be looking at the way that we work and using external tools sometimes.
Sometimes we'll roll our own internal tools, but usually it's about finding the right tools to put into streamline this work.
I don't know if you could say, hey, let's just roll this in the platform team.
That's where I see the differences, but I think the mentality of approaching platforms and product ops can be very similar.
So I hope that helps, but I do love the way of thinking of it as platform for product managers, so thank you for that.
All right, now it's time to talk to Atif.
Are you eager to dive into the world of angel investing?
I was too, but I wasn't sure how to get started.
I knew I could evaluate the early stage companies from a product standpoint, but I didn't know much about the financial side.
This is why I joined Hustle Funds Angel Squad.
They don't just bring you opportunities to invest in early stage companies.
They provide an entire education on how professional investors think about which companies to fund.
Product leaders make fantastic angel investors.
And if you're interested in joining me at Angel Squad, you can learn more at hustlefund .vc .mp.
Find the link in our show notes.
Welcome, Atif. It's great to have you on the podcast.
Melissa, it's wonderful to join you.
Thanks for having me.
So you've been doing a lot of work around problem solving and how we can create systems for innovation.
Can you tell us a little bit about your career path and what led you into those topics today?
Well, you know, they say necessity is the mother of invention.
And I think that's really the origin story for the work I've done around navigating into the unknown and creating kind of systematic ways for companies to solve problems when they start with a lot of ambiguity, which is very common, right?
It's the hallmark of trying to innovate or getting to be territory.
I sort of grew up in internet companies from the early days.
You know, I decided very early in 1996 that internet products were really interesting and maybe this would turn out to be a thing.
So I jumped right into it in my early 20s and joined AOL during their hey date, you know, as they were kind of becoming a very strong player, you know, number one in the internet business.
And that kind of spawned my career coming up through internet companies and product management and general manager roles.
And eventually I ran a business unit on Amazon.
So that was all going great.
And then in 2013, I get a surprising call from the CEO of McDonald's and wants to hire me.
And that just seemed like a complete non sequitur.
Like, what do I have to do with, you know, fast food?
And of course, he was pressing, you know, he was ahead of his time.
And this began the whole wave of digital transformation that we've seen over the last 10 years and bricks and mortar and sort of companies that are not inherently tech companies.
And so I began a shift where I was in the C -suite role and then continued to do that for 10 years at well -known companies, Volvo and MGM Resorts after that.
And really I was, in order to drive these companies forward and help them grow, I had to deal with a lot of cultural issues.
And the way to solve culture is that through slogans and words, but to invent kind of ways of working your systems for people to do their best for to be comfortable with ambiguities so that you can actually embrace new ideas and go from those on a PowerPoint to actually shipping them.
And so a lot of my work comes from the necessity of having to kind of bridge the gap between a place like Amazon, which is very comfortable with unknowns and ambiguity and traditional companies where it's more about incrementality and how do I introduce that.
So that is a lot of how my career journey is tied up with kind of the things that I write about and share.
So you wrote this book called Decision Sprint that really outlines the systemic way of exploring the unknown and how to innovate.
Can you tell us a little bit about how you came up with this framework, the things that you find in this book, and maybe an example of an innovation that you've done at one of these companies that led to it?
Sure. Well, Decision Sprint introduces the idea of upstream work.
And the way I came up with this was I tried to reflect on, hey, you know, I'm with these companies and Volvo, McDonald's and Jim Resort.
It's like, they're very successful.
What is their engine?
And to me, you know, I put my finger on the fact that they're really great at execution and that if we could add to that the idea of all the steps it takes to actually get to execution, because of course we all know that before you can execute, you have to kind of call it with recommendations.
You have to get decisions.
You have to get by.
And this process can take weeks and months for any given idea.
And that itself has a workflow underlying it.
And so I needed to first coin a phrase and give it a word or a name and I called it upstream work.
So that's the whole process of starting with a raw objective or idea and then navigating to the decision point.
And there's a lot of steps in the middle, as you know, Melissa.
So that is sort of the core focus of the book, is defining upstream work and breaking it down into not only methodology, but like workflows, 13 workflows, in fact.
You know, I don't get bored with them.
And so I distill those.
These are things that I was putting in place in the organizations I mentioned kind of implicitly, like not really with a training or documentation per se, but more in the way I carried myself as a leader.
So to give some examples, you know, I would always be comfortable meeting with teams during a kickoff where we wrestled with a lot of questions, but no answers.
And I actually encourage teams to meet with me with a great question list and having no answers to any of those questions, which was a little bit of something that took some adjustment in terms of the teams being able to collaborate with me because they felt like they needed to meet with me, with very
clear answers, kind of putting something specific on the table.
But just the idea of developing a great question list to kick off exploration or discovery work is a way in which I led and the way I conducted the meetings I had with teams.
And that's just one part of the decision sprint is the idea of building and running explorations.
I was doing this sort of through my leadership style, but as I got the time, you know, I decided to write the book to actually distill it into specific methodology.
At McDonald's, I say we use this to launch big things, you know, things like Apple Pay.
Apple Pay is very common today, but when we got a call from Cupertino saying, we want to meet you and the CEO of McDonald's at the Four Seasons in Chicago, we can't tell you what it's about, but we're working on something top secret that's going to launch in two months.
And Apple showed us the first iPhone with a kind of C chip and asked us if we wanted to be a launch partner and that we had 60 days to make it happen across over 10 ,000 locations in the United States.
That was big stuff.
And we used the ideas that I put into the decision sprint to kind of navigate through a lot of the ambiguity of making an Apple Pay integration work.
And eventually, if we did ship, our CEO was on stage with Apple as a launch partner, so that was pretty cool.
When you come into these organizations that have not traditionally, let's say, the software run, when you come from Amazon, you come from these backgrounds where I find that a lot of places I work with that are doing digital transformations, they look up to Amazon.
They're like, I want to innovate them.
I want to do that. Did you find that it was, you know, more of a process problem in the organizations for the barrier to entry to innovation?
You talked a little bit about the culture problem.
Like, how did you kind of sift out what's standing in the way from us innovating, like Amazon?
It's a multifaceted journey, Melissa, and it has a lot of components, and we're kind of 10 years into it.
So a lot of this stuff is sort of documented, and I think I had something to do with getting some of these transformations and best practices out there.
But, yeah, it starts with talent, you know, which I think is very important because, you know, a project manager is not a product manager, that kind of thing.
It starts with, it includes mindset, moving from a project orientation to product orientation, meaning continuous and never done, right?
It includes things like focus on the customer over the internal considerations and working backwards from customer needs.
So there's this whole series of layers of a cake, so to speak, to get on this journey of transformation around product thinking.
I think where we are today is actually at the next evolution of the thing.
And what I mean by that is it's not enough to have one quarter of the company kind of really embracing the idea of product thinking or problem solving, if you will, if you abstract it, like complex problem solving.
And the reason for that is the problems are really interdependent.
Now we can get into some examples, but just having one quarter of the company working on a particular Twitch and then the whole rest of the company is working the old way, that breaks down very quickly.
The product plans look great, but then what shifts is, it just slow or it's really watered down.
So we need ways of introducing problem -solving skills across the entire organization.
And I feel like one of the limitations of kind of Agile Manifesto and all the things that came out of it is that it is kind of like a tribal language and it's not embraced by enough of the organization.
So we need things that are more accessible, more democratic in that respect.
And that's the area where I'm facing time and energy.
I think that has been a huge topic for me lately as well, because I think a lot of these ways that we talk about innovation or the way that we talk about product start from a tech perspective.
And a lot of organizations that I've worked with in digital transformations, they saw it as kind of like make IT go faster at first.
And now it's like, okay, now we need to do the product thing and not the project thing.
I understand that we need to do these things to innovate.
But then there's this kind of lack of understanding of what does it take as a whole company to shift that way.
So I'm really curious you did mention it.
There's some things that you found that worked really well to get everybody to embrace it.
What did you do to try to bridge the gap between, I guess, you know, the technology side and the business side and the sales side and all the rest of the organization?
I think there are a couple of tricks to it.
One is to meet the organization where it is, is like my first principle.
What I mean by that Melissa in practice is we're not trying to introduce some, you know, whiz -bang, you know, 14 -step process and have to train a lot of people around it.
We will start with how the company actually makes decisions today.
And very commonly, there's a stakeholder group or there may be some type of steering committee and, you know, they have a cadence of when they meet and what they like to see in order to kind of give the thumbs up or calibrate with some feedback, et cetera, et cetera.
And so I think that the working teams should plug into that and work backwards from it and say, okay, well, if we want to be at a point where, you know, we can get stakeholders to do their thing, stakeholders love making decisions, they're action junkies, right?
And how do we actually work backwards from that?
What they want to do is basically embrace a few ideas of things like, well, before you get to a decision point, when you probably need to clarify the problem you're trying to solve, come up with the key questions that should populate your exploration, discovery work, treat that as a body of work and just socialize
that with the stakeholders way before the decision point and just get some calibration that we're on the right track or are we even defining the problem to solve, you know, in a way that's complete enough or, you know, you're coming from the same perspective.
If that looked good, then all your deep dive stuff can happen, right?
In terms of getting to the bottom of questions, drawing conclusions, coming up with recommendations.
That's something which you can also calibrate.
And then in step three, you kind of have the ability to navigate decision making process because you brought people along the journey.
And this is very different than what we typically see in organizations where, you know, there's a high stakes meeting and in a short amount of time, a lot needs to be understood, the breadcrumbs need to be explained, and a lot needs to be unpacked.
And that's a lot of pressure for the stakeholders, also a lot of pressure for the team that holds the initiative to accomplish.
And so we need to actually break that down into a few atomic elements and build up to it.
And so the idea of building and running explorations, getting stakeholders and organizations comfortable that that's a good idea, it's purposeful, it's not a waste of time, it's not research, that's kind of burning energy and time, it's very purposeful.
I'm getting some blinded around that step, you know, that I think could be very powerful.
Hearing you talk, it kind of brings up this piece that I've been working on a lot with strategy.
And I'm curious what your thoughts are on it.
In a lot of organizations going through digital transformations, I find that they're setting the technology strategy and the product strategy is kind of separate from the business strategies.
And that's where we usually get a lot of conflict.
And the ones that I find that do the best work, they're thinking about their suite of products together.
And that could be digital, it could be financial, it could be whatever.
But a lot of these things are closely intertwined.
I think there is a lot of movement though in C -suites I've seen where people are encouraged to have like competing goals.
Like marketing has a competing goal to product or there's not the alignment there.
I'm curious what you've seen to help bring alignment back between what we're doing in software, what we're doing in digital and then what we're doing in the business.
And when you're thinking of decisions even at the top layer for strategy, what's that look like in your world and what have you found be successful to lead it that way?
Well, I think taking it from the CEO perspective, an effective CEO creates clarity around the problem -solving frontier of the organization.
And that is the biggest gift that the person in charge of the whole thing can give to enable everybody else to do their best work and avoid some of this misalignment or just moving in different directions.
So your problem -solving frontier is essentially, and we're very happy with what we've achieved so far, but for us to remain relevant and create the growth, reach our growth ambitions, these are the key pillars.
And within those key pillars, it's easy to see what initiatives need to be booted up, so to speak.
Now, when we put our finger on those things, we will quickly realize that any given one of those initiatives takes collective intelligence.
It can't be solved by one corner of the company.
Everything else is sort of just table stakes, execution.
If it's not multi -threaded problems, you don't have the right ambition as a company.
And if you take that as a given, the very next thing you do is try to form effective working teams around these initiatives based on the competencies you need.
And so this is the biggest gift that the C -suite can give to enable the rest of the organization.
And it's really their responsibility in my mind to do that.
Now, if they do, you know, you have working teams, they'll probably be a bit cross -functional.
They have some clear kind of, like, problems they're defining and trying to explore, you know, and to put on the table.
We need to give them a way of working together.
And to your point earlier, Melissa, you know, if you come in with your product chops or kind of your agile mindset and try and convince commercial people or people in tax or regulatory or something else, it's kind of a foreign language.
So we need a more universal language to talk together about things.
And so I'm not trying to skew it towards the way I've written it, but it is one take on things where when you talk about kind of moving from idea to action in a very accessible language, like building and running explorations, having that alignment step, working towards decision points.
You know, people in business, they kind of get these.
They understand what these terms mean.
And if you lay that out in a workflow, link to their milestones, like how, when these meetings happen and, you know, when they can kind of get stakeholders together, you know, that can be a really good framework to then enable people to do their best work and together.
So after going through all these transformations and, you know, leading these teams, you're now working on this product called Ritual that's supposed to help with some of the upstream workflow and the problem solving.
Can you tell us a little bit about what led you to look at these problems and say, hey, I think I can solve this with software.
I think there's a problem here that we need more guidance around.
I love software, and I'm so happy that Jenny and I came on the scene because it really is such an accelerator for knowledge work.
You know, in the end, the things we're talking about, Melissa, are knowledge work, whether it's the PM or, you know, another end of the company working together, working separately.
You know, in the end, it's about originating new knowledge the company doesn't have.
Because if we already knew, if we've done it four or ten times, it's institutional knowledge.
It's just execution, right?
But most of the things that take time are trying to, like, solve a puzzle and creating new knowledge that a company didn't have before.
That unlocks the ability to say yes or no and move on to the next step.
And so knowledge work is really the heart of what we all do here.
And when I think about AI, it's just really good at some things that humans struggle with.
So first, it's really good at overcoming cold start problems because you can get a raw input, and it's like, yeah, that's what I was thinking.
So that's great. It's really good at servicing blind spots because you can pick any starting point, and it kind of then gives you the cluster of relatedness around it.
And so it helps you see, you know, just like the sensors in cars, right?
Like, they see your blind spots, so it's really bad.
And it's actually really good at overcoming another human pitfall, which is limiting beliefs because, you know, you can always define a problem too small or too big or without constraints or trade -offs.
Humans, you know, the way they think about problems sometimes is biased by their own insecurities.
If you're about an innovator, then you'll think pretty small about an idea.
AI is really good about taking raw input from humans and actually addressing these issues of cold starts, blind spots, and limiting beliefs, in my view.
So I began to think, what if we actually integrate AI and embed that into workflow?
So first of all, what if we have a workflow for problem solving?
We have an idea or an objective, and we need to produce a recommendation.
We have four people on the working team, and we have a couple weeks to do it.
So that's why we created Ritual, is to make that easy and sort of make the atomic steps of that process, you know, very accessible and for any team in any organization.
And then we started thinking, if you embed AI, you know, you get additional velocity and you get better quality as well.
So Ritual is a workflow plus AI for moving ideas or objectives to down the path of producing recommendations and facilitating decision making, producing content you might need, like a memo, an Amazon -style area, an FAQ, things of that nature.
Did you know I have a course for product managers that you could take?
It's called Product Institute.
Over the past seven years, I've been working with individuals, teams, and companies to upscale their product chops through my fully online school.
We have an ever -growing list of courses to help you work through your current product dilemma.
Visit productinstitute .com and learn to think like a great product manager.
Use code thinking to save $200 at checkout on our premier course, Product Management Foundations.
So, Ritual, is it for leaders?
Is it for product managers?
How do you think about when you actually collaborate around that tool?
Well, if there's a team working on an initiative and they need to produce recommendations or suggest a direction, that's who we built it for.
There is a role for leaders as well because that makes calibration easy, meaning you'll be part of the process where it makes sense.
So in validating the problem statement, looking at a set of questions, the team is going to explore before they actually do the deep dive or reviewing the output and the conclusions they're growing based on their deep dive.
So if you're a leader, it'll just give you more transparency and just make your involvement with the team more purposeful.
So you're not in the details, which you shouldn't be.
You need to give the team space, but you can be more comfortable that their work is purposeful.
And for the team guiding you through how that purposeful work, you know, what it looks like in practice.
But we are kind of very focused on teams and helping enable them to work for ambiguity and not nodes.
One issue that I usually hear from teams when they're looking at this problem solving is the trade -off between long -term missions and short -term objectives.
How do you look at your problem solving framework and what you do with virtual to help balance that?
How do you make sure that it's not skewing one way into only short -term objectives and sacrificing the long?
I think where teams struggle sometimes is in framing a problem, you know, is basically I would encourage teams not to give up on long -term exploration.
Like, you have a new idea and you want to get it out of the gate.
But then at the same time, you want to be able to reach the full ambition of this idea.
And I think that usually happens in my view where things get watered down and diluted when you're vulnerable with not being able to defend the discovery work you've done.
So I think the number one sort of piece of advice I would have is basically to surface the complex sticky issues that can bite you or make the idea more vulnerable and actually embrace that those exist and spend time with them because sometimes there's simple solutions to things that seem like they're
going to be impossible to overcome.
But actually getting those down and recognizing that they exist and spending time with them, I think you may realize that these hurdles are a lot smaller than you think.
It's interesting because as you describe this, it reminds me a little bit of, I do a lot of work with Toyota Kata in what I call the Prada Kata.
And there's a step in it where once you look at your goal, you say what are the obstacles standing in the way of us reaching that goal.
And it could be small obstacles like you're talking about, it could be big obstacles.
But I find a lot of teams don't sit there and actually think through those problems first before they try to run head first at the goal or just say let's build these things or then they come up with a problem two months down the line and they go we can't do anything about it but usually they just need
to be problem solved.
So I find a lot of synergies in what you're talking about right there.
That's PMs. PMs believe in the idea of continuous exploration discovery.
But what does that actually mean in practice?
It doesn't mean that you're only running one exploration and then you get that done and then you figure out where you need to go next.
That's one way of thinking about it.
Imagine having more of a map of like we're going to be working on this for like three, four years.
This is huge. We want it to build momentum.
So we've scoped an exploration that's going to help us get something out the door here in the next few months.
But we know that concurrently there's this other thing we're trying to get our head around.
And that unlock may happen, who knows when, six months from now, nine months from now.
But we actually know what it is that we want to put our minds to.
And so just being able to, I mean, that could be perceived as like a backlog of explorations or things like that.
But I think that idea is very powerful, very underappreciated.
I would say we were very comfortable with that.
And there wasn't a method for our process.
But I would just say through the process of the tribal elders, you'd be in a meeting and we would never kill the idea that we need to go get our head around something.
Even if we knew that we didn't have the time for that right now.
It didn't mean we're going to bucket it as like on the ignore path.
It was like, do not ignore, but do not work on it right now.
Don't forget it. And we'll just know when's the right time to kind of start to really focus on intensely solving that particular problem.
And I think this idea of having some backlog of the problems that you're trying to solve is a good idea.
Another issue that I see in many organizations that are getting used to this way of working, especially in a digital transformation, is the time that it takes to do that discovery or problem exploration.
And a lot of companies out there have adopted some kind of agile methodology.
Some of them aren't safe, which I don't love, but some of them are sprinting.
And I've seen this pattern where, that I vehemently disagree with, but where we break down the work into quarters.
Fine. Don't care about that.
And they give every team just one week out of that quarter or one sprint at the beginning of the quarter to go do discovery work.
And then they're like, okay, now give me the roadmap for the rest of the quarter.
And I found that that's incredibly unnatural in the scope and the way that you would solve problems, right?
Some problems take a lot of exploration.
Some problems take a little bit of exploration.
It also depends on where your product is.
How have you balanced giving people a space in the room to go out and do that discovery work to find those innovative ideas?
And what would you recommend to leaders who are just starting to adopt this for when it comes to cadences and time like that?
Well, yeah, I mean, I couldn't agree with you more.
I think, I mean, every idea is its own animal, so to speak.
And that doesn't mean that we need to be slow about anything whatsoever.
Well, it just means that every idea has in common is needing to start with a clear definition of what we're trying to solve and trying to do a really good job of servicing the known unknowns, right?
And that's the heart of discovery.
And that doesn't take too long because it's like, come to me with all your questions, Riley.
What's all heard about that?
When you have a few good brains around the problem and it's AI assisted like it is now, that could actually be pretty fast.
Then you actually know what you're dealing with.
And within that, you say, OK, well, what's the scope of what we need to explore in order to unlock the thing we're actually trying to decide?
Does this idea have merit?
Is it worth being a priority for us?
It is very different than how do we make it happen.
Those are two different forks in the room.
So I think, sure, I mean, across all the ideas, maybe you want someone needs a view, a cut on, hey, where do these ideas stand?
But I'd rather be seeing ideas more organically progressing with high velocity, right, based on the nature of that idea.
Some are in exploration.
Some are ready to move on to execution and break them down so you can have some dates and milestones for getting them out the door.
But this is much more fluent in my view.
When you were looking at leading these teams and looking at the roadmaps and trying to communicate that to other stakeholders and other people, how did you describe things that were in discovery or being explored versus stuff that we knew we were going to ship?
This is also a big problem I find for product people out there is letting somebody know, hey, we're still discovering it.
We're not sure if we're going to build this.
And sometimes people don't take that the right way and they run with it or they promise it to customers or they think it means it's going to be done immediately.
It is a really big problem, especially in a traditional company, right, because traditional companies want one or the other.
Either someone's asking for it and there's an ROI and we're doing it and when can we have it?
Or there's a lot of skepticism around exploration, basically, because I think that's where teams are essentially just brainstorming for the sake of it.
But I think the number one thing is to basically show the connection to the problem -solving frontier of the organization.
So, for example, if you're a McDonald's, you say, look, this company is about taste, value, and convenience and we need to really redefine what convenience means in this era.
And that's our opportunity.
Well, how are we going to do that?
Well, today we have two ways of serving the customer or three.
The drive -through where you come in, stand on the line, get your tray, sit down, or get a bag and leave.
Three ways to use a McDonald's, 60 years.
Okay, well, if we can invent two more ways, would that be cool?
Yes, that would be great.
That seems like that could be pretty, some pretty big numbers if it works.
Okay, well, here's the five ways we're considering to introduce new service bottles.
It's curb size, table service, it's delivery for aggregators, it's delivery to our own kind of network.
You know, these are the ideas.
Okay, well, here's where we are on a curb site.
For example, we are exploring basically when we should put the order into the kitchen because, you know, maybe the data is not accurate around where the customer is.
The food will get cold, something like that, right?
It's very specific.
So we have to work backwards from the problem -solving frontier that is tied to the strategy and the growth of the company and tie it not only to the initiative, but the explorations that actually are purposeful because they're going to tell us, yeah, lean in or, hey, park this, this is not doable, let's
find a different way.
That is kind of the journey that we need to take people through to get them actually to be really advocates for exploration.
Yeah, okay, now that you mentioned it, have you thought about here's the question you should be thinking about or here's someone you should talk to.
Now you actually get more advocacy and buying for the idea of exploration.
So that is what good looks like, you know, obviously that takes a lot of work to get there.
When companies are embarking on digital transformations or trying to introduce innovation, I find that sometimes they can run really fast and people can burn out.
Can you talk to me a little bit about how you think as a leader about sustainability when it comes to innovation, making sure that we don't just one -time it, but also in employee engagement and how to keep that going?
Yeah, my view on sustainability at work is essentially that, number one, it's all about contribution.
So people need a way to be heard and seen.
Number one, that allows them to attempt a contribution and that contribution, I think, should stand on its own merits.
You know, if it's great, we'll tell them it's great.
It's not great. We'll tell them it's not great.
So I don't believe in just, you know, sort of like telling everyone, everyone gets an A, you know, that's not going to work in life.
I'm sorry. But I think people really appreciate that mechanism for contribution is having the space to contribute and then seeing that that contribution impact in the work is somehow integrated and reflected in what we decided to do.
To me, that is ultimately the core kernel of what creates energy or regenerates energy for the work that we do.
So to make work sustainable, I think that's the number one unlock.
The second thing is that fits and starts are very taxing on people emotionally and energy wise.
And in digital transformations or just any work in organizations, if everyone's really excited and then, you know, then there's a pause that we don't know why.
And then all of a sudden, it's like, let's go.
We're going to slow.
How fast can we go?
You know, that's just confusing, right?
Because we don't really understand why it was accelerated and decelerated.
That's good. If you play basketball because you can throw people off and make a shot, but it's not good in business.
You know, we need more stability.
So there I would say we need methodology for problem solving because the reason why the randomness of like a project having fits and starts is because some people have a great idea.
Others didn't follow that process, right?
We didn't bring people along.
And we need a methodology so we can validate that we're bringing people along as we go from a raw stage to decision points.
When you're thinking about sustainability of innovation and in the workplace, do you measure it anyway?
Is there some kind of way you're tracking it and making sure we're on par with what you want to see?
That's a great question.
I mean, I haven't thought about like quantitative measures, but I think it's easily pretty noticeable, let's say, in terms of whether people are contributing to something which makes light bulbs go off in your head.
So if you've had somebody that usually makes the light bulbs go off and it's been a good thought partner and then it's not there, that's pretty much a clear sign.
So for me, it's always been about the degree of thought partnership that I'm getting from the person.
And when people become order takers, that's very dangerous, right?
And you have to listen for that, you know, because then they've sort of resigned themselves to just kind of doing what the company has told them to do, which is not knowledge work, right?
Because I would never want to be in a situation where I'm the only person deciding what to do.
We need rich input from many people in order to get to the right decisions.
You have been working in corporations for quite a while, and now you started this startup.
What did you have to learn or what challenges did you maybe not anticipate moving from the corporate world into the startup that you're thinking through now?
Yeah, so I had the benefit of starting a company in my 20s, and I'm not in my 20s now.
So there are things to learn or relearn, Melissa.
Yeah, your question is a great one.
And, you know, obviously, when you're the C -suite, you're president of a major company, you know, you have four people in a garage.
It's entirely different, right?
You have to roll up the sleeves, all that good stuff, which wasn't a big adjustment for me, just because, as I mentioned before, I kind of had that in my blood and my roots.
But I think the number one thing about being an entrepreneur is that you have to initiate and create the momentum.
All the momentum will kind of come from you at the start.
And so, you know, there's nothing that's already there where you're just trying to enhance the momentum or re -energize it.
You know, you have to create the momentum.
So, and that starts with your idea.
Your idea is probably going to be ahead by two years, maybe three years.
And then the world wakes up and starts talking your language.
But in the beginning, they were like, we can't even understand what you're talking about, right?
So you have to really push yourself to kind of stay true to your North Starry.
Your inherent conviction is probably right.
That's my view. If you take a leap of faith and give up a lot and become an entrepreneur, you probably have a conviction that has some truth to it.
Now it's about kind of landing that truth and trying to simplify and make it work in the language of the world, the way people think about things, you know, really, you know, on that path to the product market fit.
So I would say just that idea of sticking with your conviction, but just chipping away at kind of how it's defined and how are you trying to land it in the world.
That's the number one thing that, you know, I had to work on in the first couple years of this journey.
So I know it's definitely shows your conviction to this problem solving methodology and helping ritual help people.
So I think you're killing that piece.
Talk to me a little bit about what you're excited about in technology in the future, right?
We've got this. You mentioned AI.
You were very excited about LLMs.
What are you looking at as a founder of this company about how things are going to change and what are you anticipating?
I anticipate a lot of change.
You know, Wall Street Journal had like a story about disappearing white collar works six months ago and had a long interview.
They only use one quote and it happened to be the lead quote of the article, which was there'll be much fewer jobs in the future.
And so that was a little bit of the, you know, glass half empty view.
But yeah, my view is actually that's a true fact that I think will happen.
But glass half full as well, you know, because I think a few things will happen.
I mean, what happens in today's world, you know, it's like a lot of promising ideas, not as many get off the ground teams have a hard time kind of working with each other, you know, companies get in there all the way.
There's a lot of silos.
I think a lot of the human factors are a challenge today.
You know, you can have a dominant personality, which doesn't take things in the right direction.
I think there'll be a lot of error correction, course correction through AI around knowledge work and it will allow people to do their best work.
It will allow the great contributors to be seen and to make those contributions and impacts and get rewarded as such.
I think that's kind of the world that we're entering.
I think we'll see a decline in the McKinsey's of the world.
I think I was always anti outsourcing.
That was my number one slide for any board is like project to product.
What is the number one thing side from talent is we're from outsourcing to insourcing because you have to take control of your own destiny.
And we're going to move to a world where we democratize problem solving skills.
We upskill the people that we actually have because we hired them for a reason and allow them to do their best work.
So we'll see a lot of change in terms of the corporate construct that's out there right now.
It's very exciting in a lot of ways, but I think you have to be able to embrace the new tools.
I hope we're part of that.
I think everybody who's listening to this podcast right now is cheering at the thought of internalizing problem solving and not hiring McKinsey for it.
So we're all looking forward to a world that looks like that as well.
Thank you so much. You've been a fantastic guest.
I want people to go check out ritual.
Where can they learn more about you?
So ritual is ritual .work and then you can look me up on LinkedIn and I do check my messages there if anyone's feeling curious about something and then can read more about my work and some of my latest thoughts on decision sprint .com.
Great. And we will put all of those links on the product thinking podcast website.
So go to product thinking podcast .com and we will make sure to link out to all of that in a book as well.
Decision Sprint. Thank you for listening to the product thinking podcast.
We'll be back next Wednesday with another guest.
So make sure that you like and subscribe this so that you never miss another episode.
If you have questions for me about product management in the meantime, go to DearMelissa .com and let me know what they are.
We'll see you next week.
