Classic product planning - Strategy --> Roadmaps --> Project plans - is hard work and yields far less value than we think. The plans quickly lose sync with reality, projects run long, and outcomes are often disappointing. Worse, this type of waterfall planning limits our ability to innovate and to stay agile, and it does not factor the high level of uncertainty tech companies face.
In this talk, Itamar presents an alternative planning and execution system that I started using while working at Google and further adapted and implemented in numerous companies. The system is called GIST after its main components: Goals, Ideas, Steps, and Tasks. Together the four parts create a lightweight framework for planning and execution resulting in plans that are built for change, require less management intervention, improve team velocity and autonomy, and ultimately deliver better products and value.
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
All right, everyone. Very happy to be here in TuringFest online version. And today I want to talk to you about GIST framework, which is sort of a product discovery framework, if you like. And its main goal is to help us build high impact products.
And I realize this is something that requires explanation, so let me try and explain. Fundamentally, every organization needs to do two things: focus on a mission that involves two parts: delivering value to a market and capturing value back. And ideally, of course, we want to deliver high value to a large market and capture a lot of value back and create virtuous loops between these things.
As product managers and generally as product organizations, it's our mission to find the product that enables doing these two things best those high impact products. And as a product manager, as someone who's been in product organization for many years, including at Google, including Microsoft, including a number of startups, I found that this is actually the hardest part of the job.
This is the most challenging part. And I would argue that most of the time we're not doing that well. In fact, the project distribution or the impact distribution over projects history looks a bit like this. And I would argue it's typical of the entire industry, but this is not very scientific.
Sometimes we stumble on really big successes, things that really create a step function or exponential growth, but those are very, very rare. I think in my entire career of twenty five years, I can point at two. More often we'll have things that have mild impact.
They're kind of incremental improvements. That's great. We'll take those any day of the week, but they are a minority. On the other side of the gamut, we have things that create negative impacts. They're either causing the customers to be less satisfied with the product or to buy less or to use less.
Some of them are real disasters, like the Galaxy Note tab that was exploding in aircrafts or something like Windows Vista. But more often than not, the negative impact things are more hidden. We launch them, we think it's good, we celebrate the success of launching, but then over time we realize we actually need to un launch them because they are not so good.
But more often than not, the customers and the users just disregard everything we launch. They don't care that we worked so **** ** designing and building this thing. And these things just don't have any impact. I think this is the biggest bucket. And naturally, nothing changes in the business.
And it should be clear that the no impact projects are failures too, because we invest so much time and effort in these things and eventually they yield nothing. We complicate the products, we kind of make the user interface a bit too complex and we get no benefits from those.
So the question is, why are we working mostly in failure mode? What's going on here? I would argue it has a lot to do with planning and execution. These are two topics that I see coming again and again in product and in project retrospectives.
So what's going on with our planning and execution? So most of the companies I worked for or worked with are doing some variant of this. And this is kind of a very old fashioned form of planning, but we still hang on to it.
So we try to plan the long term through something we call a strategy. Then we try to plan the intermediate term through roadmaps. And finally, tactical things are encapsulated in projects. And then we move to execution, which is agile. But nothing else in this picture is actually agile.
These strategies, these roadmaps are pretty rigid. Everyone expects them to happen exactly as planned. There's a big disappointment if we try to change things and actually they cause any changes at the top cause huge ripple effect of replanning and they cost us a lot.
So we try at all costs not to change the plans. That actually is the opposite of agility. This is rigidity. There's another side effect for this planning process, which is it kind of splits our company into two parts and each part is living in their own world with their own delusions.
The top part, the planning part, is usually the domain of managers, business stakeholders, senior product managers sometimes. And these people actually think that you can plan tech projects this way. It's actually predictable. Everything will ship on time. Everything will have the impact you expect.
And you really need to explain time and again that tech projects are not that predictable. To begin with, our technology is new and not very predictable. It has a lot of risks in it. Our projects are complex and have a lot of dependencies.
Organizations are complex. You never know when an idea will run into friction inside the organization. I've seen many good ideas die just for that reason. And most of all, our markets are not predictable. Software and the Internet removed most of the barriers to entry.
And today there's so much competition, there's so many options and the customers are spoiled for choice. So we can't really expect to just conceive ideas, then plan them, then execute them as if we're launching a new can of beans, for example. On the other part of the organization, the developers, the designers, the developers, the engineers, data scientists, etc.
And they usually work in agile and they're very focused on execution. You can see how these two systems that come from different eras kind of complement each other. And for them, there's a different delusion, which is as long as we keep launching into production small increments of working code, everything will be okay.
Someone will work out what are the right requirements and someone will give it to them and their job is just to keep pushing. And that's a delusion as well, because you can do perfect agile and still the products can be horrible. So what do we do?
We put a person in the middle and that person on one side is called the product manager, and his or her responsibility is usually to deliver on the roadmap they didn't create often. A bit like a project manager. On the other hand, we have this other side of their personality, which is the product owner, and they're responsible to make the agile machine work, to feed it with product backlogs and user stories and epics, to attend to retrospectives, to attend stand ups, to do all this hard work on both sides of the gap.
And most of the product managers I talk with are very, very busy people. They don't have time to research the market, to talk to customers, and they are not very happy with the results of their work. So that's why I suggest a different system, which I call goals, ideas, steps and tasks.
As you hear the system, you will recognize a lot of familiar things and that's not coincidence. I didn't invent much. But I think structuring the work through these four parts actually makes a big difference and I hope you will understand it or notice it as I explain.
So fundamentally, just says that you need to plan on four layers: goals, which kind of explains what we're trying to achieve ideas, which are hypothetical ways to achieve the goals and there's always more than one idea to achieve the goal steps, which are short projects, usually a few weeks long, that develop the idea somewhat and test it.
A bit like build, measure, learn loops, if you know them from Lean Startup and the tasks. The tasks are the day to day activities that kind of implement the steps. And the tasks are exactly the things we manage with agile development today. Have plenty of methodology here.
GIST is not trying to invent anything new. It's more about connecting those to the other three layers. So let's start with goals. And I think the best way to explain what a good goal is, is to actually look at this famous quote by General Patton, and he says If you tell people where to go but not how to get there, you'll be amazed at the results.
It's not a surprise that we're getting this kind of definition of goals from an army general. War and battle are unpredictable as well. They're very random. If you send troops to battle with a very little battle plan, you're basically setting them up to fail because you can't really predict whatever will happen there.
The best option is to send them with a mission conquer this line, defend this position, etc. What they will do in the field may change. They will pick different solutions based on the conditions in the field, but the missions will persist. And in this way we can actually plan goals that are more robust and more resilient and we can plan for longer.
Many companies do use goals today and usually they take the form of objectives and key results, but a lot of these OKRs are actually containing very bad goals. For example, let's say a perfectly legitimate objective become a leader in the enterprise. Now the key results really need to explain what does that mean.
But what we find there is things like let's launch Project X, let's integrate with Platform Y, let's use technology Z, machine learning, the blockchain, etc. These are called output goals, and they are about activities, things we do. We expect these things to achieve the actual outcomes, but we don't know because there's so much predictability.
So they're actually the equivalent of sending the troops to battle with a detailed plan. So let's not do this and instead let's focus on measurable outcomes and impact. So impact is those things that we saw before the mission of the company, delivering value and capture value.
I will explain those in a second. And outcomes are usually about measurable changes in user and customer behavior and measurable changes in system behavior, so maybe lower bug rates or error rates. So let's start with impact. We said we want to deliver value, want to capture value.
We actually want to measure these two things. So starting with capturing value, we have a lot of metrics there, usually called KPIs. We have revenue, we have profit, we have market share, we have recurring revenue. Maybe too much. What I see companies doing is trying to optimize for all these many different metrics all at the same time, and that's kind of devoiding the organizational focus.
I would suggest let's pick one and focus the entire company on it and say, today we are most interested in revenue or in profit. This is the year where we want to break even. Here's why. And that will enable people as they make decisions pertaining to capturing value to make better decisions because the goal is clear.
And we're actually using the mission command principle that we just saw. We want to do the same thing for delivering value, because delivering value is just as important a business goal for us as capturing value. How do we do this? Is it even possible to measure delivered value?
I would argue that yes, using this tool called the North Star Metric, which actually has been used by companies very successfully to achieve great success. So WhatsApp, for example, for a very long time from early on, have measured the number of messages sent through its service.
And here's why every message sent is actually an incremental value. Between the sender and the receiver, they can send for free rich media from anywhere in the world at any time without any cost. And that's how WhatsApp is actually helping its users. So if WhatsApp on year one is delivering a billion messages and year two, two billions, we can approximately say that we doubled the amount of value delivered to the market.
For that reason, while I was working at YouTube, we switched from measuring number of videos watched to a number of minutes watched, because the videos that I watch for longer are usually the better videos to serve both the purpose of the creators and the purpose of the viewers better.
And so that's a better nostalgic for YouTube. Airbnb and eBay are two sided marketplaces and what they actually the form of value they deliver is connecting buyers and sellers or property owners and renters and enabling them to transact. So Airbnb is measuring nights booked and eBay is measuring gross merchandise volume.
It's basically the number of dollars or euros that exchange hands. And notice that none of these metrics are about how much money the company is making. It's all about the delivered value. Once we have these two top level metrics mapped out, we can start building roadmaps around it.
So imagine a CEO standing in front of the company in the all hands meeting, and instead of just repeating the mission statement that is very high level and not very concrete, he or she can say this: As you know, these are our top metrics.
This year we expect to grow revenue from two point one million to two point seven million, and the number of documents created are no star metric. We want to grow from twenty thousand per month to thirty five thousand per month. So these are very ambitious goals.
If what you're working on right now, you don't see how it's connected to either one of those, you should talk to your manager. You can kind of see how this is much more concrete and grabbing people's attention in a much more direct way.
Maybe for the first time everyone now understands what management is optimizing for and how it pertains to them. The North Star metric specifically is something that product teams can get behind, because revenue usually is something that is hard for product teams to work on unless they're directly responsible for monetization.
There are many more people involved in collecting revenue, but delivering value to customers is something that engineers, designers, data scientists, etc. Can readily connect with. Once we have these two top level metrics, of course, we can break them down to metrics trees or metrics hierarchies or metrics graphs and see how they overlap.
And those are the foundations of the goals we want to put in our OKRs, if we use OKRs. In some cases we don't even need OKRs. In small companies, this is all we need. And this also creates an opportunity to create virtual teams around specific goals that we need to improve.
Now let's move on to talk about ideas, and this is really where I see a lot of companies struggling. And here's why. Most ideas don't really work. These two very famous data scientists, one of them is a professor in Harvard University, Wanko Javi, has actually led AB experimentation with companies like Microsoft, Airbnb and Amazon.
And they came up to the conclusion, looking at many, many companies and many results of AB tests, that the vast majority of ideas fail in experiments and even experts often misjudge which ones will pay off. At Google and Bing, only about ten to twenty percent of experiments generate positive results.
At Microsoft as a whole, one third prove effective, one third of neutral results, one third of negative results. This kind of starts to explain why we're seeing this curve of failures versus successes, because most ideas just don't work And it's very, very hard for us to predict which ideas will and which will not.
And by the way, thirty percent success rate is very, very high and typical of companies that research the market very intensively. What we usually see is much lower rates of around ten percent. So what do we do about this? We can adopt the scientific method, which is to test many ideas, which is what Linus Pauling has explained here.
Test if you want to find good ideas, you have to test many ideas. Most of them will be wrong. What you have to learn is which ones to throw away. How do we do this in our product? So as an idea comes, we don't try to fill them based on opinion.
We put them somewhere, say an idea bank, and then we can rank them. I recommend ICE, which is a system to rank ideas based on impact, confidence and ease. But you can use whatever you want. Then we pick some ideas, maybe top ranking ideas based on ICE or maybe ideas that just seem promising, but we want to use intuition in this case inside of ICE scoring.
Maybe for political reasons we have to take them, but we're not going to build any eighteen months project around any of them. What we will do is we will test them in inexpensive ways, evaluate and test, and this will generate evidence and the evidence will let us re score them.
And some ideas will go up and some ideas will go down and we can readjust our investment. Here's an example of an idea bank. It includes impact, confidence and ease, the three elements of ICE, each one in the range of zero to ten, and we multiply the score to get an ICE score.
But the problem is that assessing impact and assessing ease or effort or cost, if you like, are very subjective decisions and are subject to many biases, including this one that was called the planning fallacy discovered by Kahn and Tversky, the fathers of behavioral economics.
When planning, people and teams tend to be overly optimistic, underestimating the time, cost and risk and at the same time overestimating the benefits. This happens to all of us. We fall in love with an idea. So we cannot trust the impact and ease just based on our guesses.
We have to have this third element of confidence. And confidence is based on evidence. We have to ask ourselves what evidence do we have that this idea will actually generate the impact we expect. So there are various forms of evidence. I created this tool to kind of help us weigh them out.
And this tool is called the confidence level. It's like a calculator. You fit in all the evidence you have and it kind of shoots out a number between zero and ten. You can notice that the low confidence elements are all based on opinions or themes like the blockchains or machine learning or team opinions.
And really to gain confidence, you need to start doing estimates and plans. You need to collect anecdotal evidence from the outside. Need to run surveys or fake door tests or do in-depth competitive analysis. Need and to really gain medium or high confidence, you need to go and test with customers and users through qualitative and quantitative methods.
And really maximum confidence comes only from launching the idea and tracking it. So this tool really helps a lot of companies today to countermeasure their opinions and biases. Now let's move on to steps. How do we test an idea? So having an idea in our hand that looks good on paper is not enough.
Building a project, a nine month project, three month project is not a good idea because usually it takes longer than we expect. And again, it will not deliver the promised impact. Instead, of course, what we want to do is to build it in shorter milestones.
And those are learning milestones, not engineering milestones. So basically we want to build something small and learn. And then adjust the idea a bit and test it again in a more in a harder test. If the idea survives everything, the idea we end up with is much more profound, much better than the idea we started with.
And each one of these short projects that lead to the learning milestone is called a step. If we do this consecutively, we can see something interesting. Our level of confidence in the idea grows the more evidence we are and it's easier for us to invest in it.
While the ideas that actually have lower confidence, we realize we need to stop investing in them and we get the ice cold changing over time throughout our experiments. To further illustrate to companies that it's actually possible to gain evidence early without building code, I created a little framework which I call AFTER.
It stands for assessment, fact finding, tests, experiments and release. These are basically the forms of validation you can use. Assessment is all about just assessing the impact and the ease and the risk in the product in a more structured and less emotional way, I would say.
So like goals alignment, ice analysis, business modeling, etc. Fact finding is about going into our data, running surveys or doing user interviews or field research, etc, just to get some data even before we start building the idea, just to test it a little bit better and seeing if we can find supporting evidence this way.
Ideas that still look good after this phase can go into tests, but initially the initial tests are just testing the idea and concept without any working code. Then as we gain more confidence, we can build more and more evolved versions of the ideas until the final ones are almost complete.
And we have also experiments. I differentiate between tests and experiments. Experiments are tests that have a control element, so it's less likely that will fall into false positives or false negatives. In the industry, all of those are called experiments, but I prefer to use this term that is closer to statistics.
So AB test, ABN test, multivariate test, and even the launch itself can be a form of test. If we use this system, we can run through many more ideas and eliminate many more early on without much investment. Let's put the whole thing together.
So I found that teams really benefit from a view just like this. This is the gist board. It can be a physical board or it could be a digital board. And it just lists the goals we're working on right now, the set of ideas we are testing and the next few steps with their owners.
And it's really good for the team to meet around the board and discuss at least every week or every other week just before they go into planification. This will give them a lot of context and will save them a lot of unnecessary explanation and handling later.
And generally speaking, what gist does, it creates a continuum between the business goals and the tasks. So the developers understand why they're doing the task, they understand they're connected to steps that validate an idea and is connected to a goal, maybe they contributed to all of those.
And the managers and business owners are very involved in creating the goals. They can contribute to ideas, but they can see how their ideas stack up and they can also see the steps and see the evidence that is accumulated. And that kind of makes them trust the team a little bit more and delegate.
And for the product manager, this is a more interesting and more impactful role because the product manager now is driving discovery, is actually guiding this entire process. If you're interested more in gist or want to experiment with any of the tools I mentioned, you can go to my resources page here, italalvilab dot com slash resources and you can find many free downloads available on my site.
Thank you and I'm happy to take questions. Okay, so much to get into with in that talk for me tomorrow. So we're going to bring them back back in right now. And for anyone in the audience with questions, fire them in, and we'll we'll get them across to you tomorrow.
So first of tomorrow, thank you so much for for that exceptionally detailed. There's so much and I think I'm gonna have to watch that another three times. I've really seen it twice. Where let's pick a good place to start maybe which is the, maybe the overall purpose of GIST and and, sort of a high level question around around culture.
It seems to me that one of the main purposes of GIST is to make sure that everybody understands their role and the role of all their colleagues and how it all sort of comes together. How important do you think that awareness is for successful product teams?
I think when you work for companies like Google or other famous companies that employ principles like this. I mean, Ingesta didn't invent anything new. I just packaged existing principles that drive advanced or modern product management. The roles play less of a part. It's more about the team.
It's more about the collaboration and getting everyone to contribute in a way that is not very departmental. So what GIST actually tries to do is to break some of the walls that exist today between management and developers, between business owners or stakeholders and developers and product managers.
And to create a system that is kind of for me more unified and more collaborative. So I think it's very important. I think that all of these people have a role to play, but we need to tweak a little bit the roles in my mind.
I don't know if this answered your question, but this is the first thing that comes to my mind when we talk about this. Yeah. Mean, of your experience has been extremely complex product orgs where you've got, you know, so many different people working on on on a product or even on a subset of a product.
So communication and and awareness is gonna be so important. And then at the other end of the spectrum, I suppose, like, for example, at TuringFest, we've got a lot of a lot of startups where there's maybe ten, twenty people in the company. And so the product team might be maybe two developers, a designer, and a PM, or maybe, you know, might even not not have a PM.
So I guess from from a from is just a framework that can be implemented for smaller organizations? Or is it something that that happen works better with larger organizations? What are the I guess, are the the cultural takeaways on the the communication takeaways?
So not only it can, it's actually being used by startups. Some of the earliest adopters of GIST were my clients that were startups here in Barcelona, actually, many of them and some in Israel. And GIST is basically lean startup in a sense. Like a lot of the principles come from lean startup and these principles apply in my mind also to medium and large companies.
And I think you do less. It's less bureaucratic. You invest less in the process. There's less of a communication issue in small organizations. But there's still this dire need, especially in a startup, to define good goals, to be very, very picky about the ideas, so really to find a way to prioritize based on evidence, to keep testing very quickly, iterating through build, measure, learn loops, and to make sure that the team is engaged and understands it and is not just submerged into task level.
So I think this applies to startups just as much as it applies to enterprises. And I think that in a sense, what we're doing is bringing some of the startup spirit into enterprises and trying to force them to stop being so bureaucratic and departmental and top down and to embrace this more lean and agile form of development.
And that's really the challenge. I mean, gist, I think, fits most in organizations that want to become lean and agile, but struggle with this. And it's a huge struggle. And almost every company that I meet, including some parts of Google when I worked there, were struggling with this.
So that's really why I created GIST to help with this transition. Yeah, it's I mean, it's fascinating. And you mentioned the Lean Startup that we're I think we're nine years in from when Eric Rees published his book. And then he was building on his own experiences and stuff he'd learned from Steve Blank, amongst others, and incorporating all of that.
It's kind of it's kind of cool to see that there's still there's still so much to build. I mean, I remember when I first read that book, it's a very thin book, and you're like, oh, this is actually, you know, there's not much in this.
It's it's, it's important, but it's easy to get your head around. And then we go through the details in your in your deck there and your break like ten years later, we're still breaking this stuff down. It feels like, you know, big all these problems are people problems.
Right? But something that you mentioned there was about measuring impact. And you talked about North Star metrics. We've got John Cutler. You you probably know John from Amplitude. He's gonna be speaking in a couple of weeks about the North Star framework. How did you use that in your time at Google talking about focusing on a small number of metrics?
For example, when I worked at Gmail, I was kind of leading the growth initiatives. In general, everything we did in Gmail, there were so many metrics we could focus on. There were so many users. We've grown during my time in Gmail from four hundred million to over a billion.
And they were dispersed over so many countries and there were so many patterns. And we had consumers, anything from my mother, up to information workers. So it's really easy to get lost in all the data. And that's why it's super crucial to find this core set of metrics that are vital.
These are the things you look at day in and day out. These are the main things. And if these things dip, you are very concerned and you jump on them. And then you leave room also to do exploration of these other metrics. But it's really important to have the call metrics.
And I only discovered the Nostalgic metric concept later and it seemed very empowering to me. So instead of focusing on ten core metrics, you focus on one that represents the most how much value you're delivering, which honestly is the most important thing for any technology company.
We're all there just to serve the customers at the end of the day. And of course, we want to create a business, but without delivering value, we cannot do this. So I think Google inherently had this because Google is a very user and customer focused company.
I find that an nostalgia metric is very important for companies that kind of lost their way and are over focused on the business side, on the revenue, on the profit or over focused on the product. So creating very polished, very robust product. So the North America kind of pulls them out of their bubble and forces them to look at the market, at the users and ask ourselves whether or not we're delivering value consistently to them.
Yeah, it's a and it's a, I guess once you start to narrow down on a small number of metrics, it makes you really prioritise and focus and understand what are the most important things and what you're building and who you're building it for.
There's a question that's come in from one of one of the audience. Robbie Law asked the question. It's a great question. What happens if you discover that your North Star metric is wrong? How do you I mean, how do you go about evaluating that?
That's a great question. It's actually a common one. And it can happen. I mean, if you look at Facebook, for a very long time Facebook was optimizing for daily active users, which was the right metric for them, both because it was important for them for growth purposes, but it's also important for the users to discover other active users.
And the more active users they are on a social network, the higher the value it delivers. However, if you keep focusing on this for too much and you neglect some other things, you might run into issues. And we see Facebook running into these issues almost on a daily basis in the news.
So you need to always balance the nostalgia metric with a set of other metrics, health metrics, customer satisfaction metrics, whatever it is. And you need to keep asking yourself. And usually I think this is a yearly exercise. Are we still on the right nostalgic?
I see it with startups that sometimes they have to iterate through North Star metrics, either because they cannot measure really what they want to measure or because they still are not sure how they deliver value in the best way. For a more stable company, I would say every year you can have this discussion, how are we optimizing for the North Star Metric, the right one, and you can change.
We're agile. The whole idea about here is about agility and being able to change on the fly. Yeah, yeah, absolutely. Interesting as well in your the waterfall diagram and how you know, we've got waterfall from management and product teams being agile on the bottom and the tensions between those two things.
It's funny how and still, know, we're a long time into agile as as a sort of standard practice, but waterfall just refuses to go away. Something that you mentioned in the talk, connected to your last point, gathering market data being big key to having product confidence.
And I guess goes back to the metrics question. In a large product org like Google or Microsoft, there's a lot of resource out there to gather that market data for startups. What's a what's a good way to go about it, or perhaps even a proxy for having that that data?
So you mentioned Steve Blank and Eric Riesen. Of course, Steve Blank, what they teach startups is go out, leave the building and discover the market, discover new customers. And that's a crucial skill and a crucial activity that the founders have to take part in.
And basically everyone in the startup should contribute to it. And I would argue there's very few more important things to do in a startup than talk to your customers. And that, of course, is not scalable. It takes time. It's creating some data to process later, but it's vital.
And that's what startups start with. Qualitative research, field research, interviews, user studies, etc. As you start having a little bit more data, you can start running more advanced experiments and you can start playing with data. But you can use surveys before that. You can use Wizard of Oz tests.
You can do a million things. I've shown there the AFTER framework. So startups can start very quickly going through the early steps and getting market data early on. So something that came up in a talk earlier from Ron Lavrey from FreeAgent talked about delegating responsibility and autonomy in teams.
How do you think about balancing autonomy with the structured framework like GIST? So first off, this is probably the biggest issue in everything we try to teach and change and transform in organizations. And it comes down to trust. I mean, managers want to delegate.
When you speak to managers, they always say, Yeah, I wish I could just trust the team to do all of this that you're suggesting. But either they're junior or they don't have the right culture. They're not Google engineers. I heard so many times that, yeah, you're used to Google engineers, but our engineers are not Google engineers.
And I have to say, this is all nonsense. Once we put the system in place and the managers see that these people actually what they're actually capable of doing, all these things go away. So it's about establishing trust. And once you have trust, gist and similar systems of course, gist didn't invent much.
We have product discovery from Alti Kagan. Have been a startup with design thinking. All of these systems are about empowering teams. And Multi Kagen wrote fantastic articles on this topic and is publishing a book. So it's all about kind of finding ways for the business folks and the managers to let go a little bit and trust the teams to actually find solutions that address the business goals instead of dictating to them solutions.
And again, it's very hard to get going. But once you do and the trust is starting to be built, it's a very rewarding experience. So you've been a senior PM at Microsoft and, and also at Google. And they seem like they're, they're two pretty different product organizations, two different philosophies.
How did how did they differ? Which do you prefer? How did that work? To begin with, both were amazing schools for me. I learned so much and most of what I put in into and well, a lot of what I put in gist came from Google and from my experiences afterwards.
And I learned a lot of interesting things in Microsoft, but this was early 2000s. So we were before this wave of lean and design thinking and agile was just getting started. I practiced agile for the first time around this time in Microsoft. And Microsoft at the time was complete waterfall.
It was like the epitome of waterfall. And we would build like an eighteen month project with two hundred engineers trying to plan the whole thing in advance and having to go through terrible replanning sessions and chasing bugs. And it was horrible. But it was a bit for a reason, because at the end of the day, had to do what's called release manufacturing.
We had to burn the bits into a piece of plastic, put a piece of plastic in a cardboard and ship it. So we had to force ourselves to create a perfect product, if you like. Today we can we don't need to do this anymore.
This is history. So Google is actually the was one of the pioneers of what is the modern way of developing software in a sense, the continuous deployment, etc. And the culture is very different because of that, and there's far less emphasis on QA.
There's much more emphasis on autonomy. And what's similar in both companies is that they are kind of engineering driven companies. They really empower engineers to take the lead. They really believe in engineers as a creative force. And that's part of the secret of the success of both companies, I would say.
A question that's come in from Catherine Stables, who kind of follows on a little bit from what you're talking about, about trust and autonomy and those difficulties. How is it possible to try and implement it just type approach in a small team within a much bigger organization, particularly if you don't have much influence on the overall goals or strategy?
How how would you for people who are watching who like what they've seen and think that your framework could really help them? I guess, how do they convince their managers to give it a go to make the to give them the autonomy to implement a part of it, at least?
That's interesting. I'm actually in the process of writing a book about GIST and I dedicated an entire chapter just to this. And I wish I had a magic bullet that just fixes everything. But I would say this. First off, there are things you can do confined within your own team.
As long as the layers above you are not practicing it, you might feel bumps along the way because they might send you in a completely different way. They don't realize that you are actually implementing things in a more agile and lean way. So I think it's important to find an executive sponsor.
You need to find someone who believes in it, who thinks this is a good idea and is willing to create a pilot or willing to carve a sandbox in which you guys can experiment with this process. I prefer to actually create multiple projects and multiple teams doing it in parallel because sometimes the first attempts don't succeed so much.
So you don't want to create a false negative just because of bad luck. And so one tip is to actually go and find an executive sponsor. Another tip is to kind of prepare a little bit with facts about why the current system is not working, why the roadmap is not delivering on the promise, why we're always late and always getting kind of disappointing results from our projects.
And if you come with some data, it's better than just coming with an opinion and saying, you know, wow, this is great. We must try this. Try to show also the downside. Of course, tread lightly. Don't insult anyone, but try to show that there is a real pain here that we need to solve.
And that kind of helps a little bit. There are other tips. We don't have enough time here. But the most important thing is someone needs to step in and say, I'm going to try this. I'm going to lead this inside the company. And that person could be you. So just give it a go.
Good. I like that. It's the bravery of new ideas. Itamar, you mentioned the book. When is that coming out and how do we all get our hands on it? I wish I knew myself. It's one of these projects that is working a bit waterfall ish, unfortunately.
Right now it's in advanced drafts. I assume it will be Q1 twenty twenty one. But again, I've been proven wrong on this before. The best thing to do is to go to my website and sign up for my newsletter because that's where I share information about updates, the state of the book and there's options to become an early reader as well.
So if you're interested, feel free to do that. Super. Okay, Itamar, that's a that's a good note to close on. Thanks so much for joining us. And I'm sure your video is gonna get a ton of attention. There's a lot in there for people to digest.
There's gonna be rewatches of that for sure. So thanks for joining us, and we'll see you in Edinburgh another time. Pleasure. And thank you for inviting me. I really enjoyed it. Super. Take it easy, man. Okay, so Itamar's book if he gets it out in time.
And if we're all in in the same building the next August, maybe that'll be in our in our bookstore at next year's Turing Fest. But it's been interesting today, three, three pretty dense talks, there's a lot a lot in there to go back over.
We've covered a ton of ground. But we've seen, it seems to be that the theme of trust has been a recurring one throughout all three of those talks. I'm sure we're going to revisit that again, over over the next few weeks of the conference.
So that's that's a wrap really for today. A quick thank you to our platinum sponsors who are part of the making all of this possible. We've got Amazon, Current Health, Deliveroo and Mailchimp. They've got booths within the within the web app. So you can go check them out.
Book a time to talk to any of them. The the other thing to mention as well, on Thursday, we have Professor Debbie Shreedhar. I'm very excited about that. She's she's been such a, an oasis of calm and wisdom throughout this whole COVID experience.
Definitely check her out on Twitter. She's she's, she's very optimistic as well, which which is helpful. But we're going to be I'm to be chatting with her on Thursday. We're it's a it's a pre record. So we don't have live questions afterwards. So please do get questions in before noon on Thursday, either at the Turing Fest, Twitter handle, or even just email me directly brianturingfest dot com.
And we've also got roundtables on Thursday, the four roundtables, one on green economy and opportunities therein, one on crowdsourcing and the pros and cons. Another one on psychology and marketing. That's with Andy, who was we were speaking to earlier. And then we've got a final one that we're trying something new, we've got just a general AMA.
It's a chat with Tanya from Turing Fest, my colleague. And that's there's no there's no topics, no subject, it's just giving an opportunity for people to drop in and say hello and have a chat. So I guess it's the it's the coffee shop of the conference, if you like.
So that's all of that on Thursday afternoon. And broadcasting Debbie's interview at four pm. So I'll see you all then. But for now, that's it. Thanks for joining us.
