Ramon Guiu
Transcript
So I've been invited, I'm very happy to be here. I was invited to share my experience. I'm not an expert or anything, I just happened to find myself in a position in a company where we transitioned from Waterfall to Agile. It was a scrum, not Kanban. And I just want to share our experience as we iterated through the process and we did, you know, we tried different things. And I want to share what things worked, what things didn't work, and hopefully that's something you can take with you and see if it can apply to your, you know, specific environment. Again, every environment is different, so you'll have to see.
So just before I start, how many people here are product owners or product managers?
Okay, and how many of those that raised your hand are doing that for commercial products or products that you offer outside the organization?
Okay, like I said, just a few. Okay.
Right. Before I start, it helped me to work through the history of product management to understand how we ended up where I was at the beginning and how we transitioned through that process. And so the modern product management can be tracked back to 1931. This was the gentleman called Nate McElroy. He worked at Procter& Gamble, which is this big, fast-moving, consumer-good organization. And back then, marketing usually was organized. There was no product management. There was a centralized marketing function that was managing all the products of the organization. And this gentleman wrote a memo where he said he defined the concept of brand men. And those were people that were completely responsible, had full ownership about a specific brand inside Procter& Gamble. And they were in charge of sales, in charge of the product, in charge of pricing, etc. And the most important thing he said is that in order to be effective in their job, they had to do this through continuous testing and being very close to the customer, interacting a lot with customers, which was not the case at the time. So this was pretty revolutionary. And back then, the way they did it was...
was through the use of the traditional marketing mix. It was about getting the right product at the right price, in the right place, and with the right promotion.
So things, you know, history continues. And interestingly enough, Mr. McElroy was an advisor at Stanford. And at Stanford, there were two guys called Bill Hewlett and Dave Packard, who were entrepreneurs and were influenced by his thinking around, you know, brand men. And they took that and they interpreted that as putting decision-making for product management, product development, very close to the customer. And then the product manager was the voice of the customer inside the organization. And actually, it is this policy, there is a book about the history of Hello Packard, and in this book, they attribute the fact that they had 50 years of consecutive growth, year over year, 20% growth. They attribute that to that specific policy, being very close to the customer when designing the product. When just-in-time manufacturing came to the West, Hewlett-Packard was one of the first who adopted it. And, you know, as you can imagine, Hewlett-Packard was growing, and there were a lot of people, you know, working there that left their jobs, joined other companies, they went on and started their own companies. And so this culture of being very customer-centric, brand vertical, and lean. manufacturing, you know, just was transmitted throughout the whole ecosystem in Silicon Valley, and from there it just, you know, went all over the world.
Now, if you think about it, and we go back to fast-moving consumer goods, building and commercializing soap is not the same as building software, or technology products in general, but in particular software. So for soap, as I said, you know, the fast-moving consumer goods, because the development of the product is, you know, is slow, you know, you cannot, you know, you have to imagine, you know, you have to develop a toothpaste or you have to do the testing, and then you need to have the manufacturing facilities where you can do that. You need to ramp up production. You need to commercialize, put the product, you know, find the channels, put that product in the stores. It's a very slow process. You cannot... If you are a product manager, you're focusing most of your time not in the actual product, but you were focusing more on the last three P's in the marketing mix. So it's the pricing, the promotion, and the placement. Now, for software, this is very different. You have to imagine, you know, Still today, software is transforming completely industry, inventing new industries. And the development of the product is very connected to the commercialization, to the user needs. So this broad, this change has...
the product development very much, again, into the role of product management. So this is, again, a big change in terms of how product management functions.
And not only that, so because everything I was explaining about the process for developing a product being slow and having to make huge investments up front about facilities and ramping production, etc., they used a project management process that was waterfall because they needed to plan everything beforehand. You know, you cannot, okay, let's build a new manufacturing facility and let's test it. You know, it takes us one year to build, let's test it. I didn't work, okay, now we will iterate and change it. It was too expensive, right, to do it. So again, the problems, typical problems, you know, with waterfall process, the validation comes too late into the process. The fact that change is expensive and disruptive. So actually, waterfall works well when you don't want to do any changes at all. You want to plan everything beforehand. And then, you know, it's a slow response to market changes. Okay, nothing new here. So then came la révolution, right? And not this one, but this one. So the internet, you know, the late 1990s, brought a complete new way of delivering software. And that is, you know, when application service providers were born. That's what they were called at the time. Today you can think of software as a service company, that is sort of a natural evolution as we've moved to this, you know, so... business model. But this changed the ecosystem, the landscape completely, because now you could put a product out, get feedback from customers immediately, so you didn't need to distribute it. I just put it, everybody can access it. I can get feedback. And if I need to update, I can do it very quickly. So the risks of making a mistake are a lot lower, because if there is a mistake, I can fix it very fast.
So people that were trying to use Waterfall with this new model were struggling. It's not working. Waterfall is for a very predictable process, a more longer process, a lot of predictability. I don't want to take risks. I want to be sure that whatever I release, it's going to be stable, it's going to work, etc. But with the internet and with the pace at which technology was developing, this was definitely not a good thing.
And that is when agile methodologies became a lot more popular. So the two movements are very much connected. So this is just a very short introduction to the history, as I see it, of product management and where we are, how we've gone to where we are today. And I'm going to focus more on my particular experience. But this has a lot of commonalities with this transition.
So this is me. I'm Ramon Guill. I come from Barcelona. I've been working for 14 years in startups, build software, the commercialized software. 10 years in particular leading products, more product, sometimes not called product management, but anyway, leading the definition and the strategy on the product. I've been an entrepreneur before, and I've worked on many different roles also. I've been in development, in QA, project management. And I'm also a co-organizer of Product Tank Barcelona. Don't know if anybody here knows about Product Tank. It's an event that is held in many different cities, 80 I think right now. There is one in Paris. They had an event early in November. And it's about people like you going and presenting and sharing their experiences. So you can all learn from each other. I recommend that you look. There is a meetup group where you can subscribe. To their events.
So we're back 2011, and I joined Xylem. Xylem is a company that builds a content, we offer a content management system for learning. And we sell it to enterprise organizations, very large organizations.
And it's 2011, I joined the company, I'm the first PM to join. Okay, so we were 30 people at the time, and product management was being led by the owners, of the founders and the owners of the company. And they decided they wanted to bring somebody on board to put more structure, have somebody dedicated to capture feedback from customers, building a backlog, a roadmap, and again, so structuring the process of building the software.
And so we were 30 people. Just bear in mind that also I'm going to talk between 2011 and basically today, you know, where we are and what we're thinking in terms of where we're going to go next. Bear in mind that we're 30 people, and through that period, especially the four first years, we grew from 30 people to 120. So it's also, we're growing very fast, and not only that, is we're remote. So I don't know if there is a lot of people here that work remotely, but of course it's a very different experience, right?
And also, you know, very, very challenging.
So if we go back on 2011, you know, and we think about Xalim at that time, the software that we sell, so we sell to enterprise organizations. Think about very large organizations, very averse, very risk averse, you know, the one that's taking a risk, security, very security conscious. So software at that time was installed many times on-premise. And that was our case for the most part. Most of our customers didn't want us to host things on the cloud. The cloud? I mean, what's that? I mean, no, no way. So we were, they were hosting, we were installing the software on their servers. For some of them, we hosted it ourselves. But those were some of the, some exceptions. We sell perpetual licenses. So the model is we would sell, you know, get a big upfront payment, and then maintenance fees, you know, 20%, usually maintenance fees, every year. And the problem with the model is, of course, compared to SaaS, well, the good thing is that you get a lot of money upfront. The problem is that every year you have to sell a lot of licenses if you want to grow. You know, with SaaS, SaaS is a lot different. We use a waterfall process. So when I joined, we were in the middle of finishing a new release of the software that had been under development six months. I joined in January. If I recall well, the release went out the door around May, I think. So it was almost a year between the last release and the new one.
And bear in mind that our customers were not necessarily, they were okay with that. Again, as I said, they were risk averse. The software needed to be installed on their system. So, okay, you install, it works for us. We have tested it because they tested internally. We're fine. I mean, don't touch it, actually. They say, no, don't touch it. I mean, it's working for us. We don't want you to change it. So why did we transition to Agile? The problem we had was sales. Is that in order to grow in the sales process, we had to become much more agile than our competitors that were more established. And in order to convince customers to sign for us, we were more flexible in terms of, okay, you need this, we can deliver it faster than our competitors. Just be in mind, our competitors were all using this process as well. So they were releasing every year, every 12 months, 18 months, a new release. So it was not really our existing customers. It was sales that was, you know, the sales need and the need to adapt quicker to the market needs that prompted our transition to Agile.
So this is what I was doing when I joined. And again, that's more or less the first six months, six to eight months. And so I was doing the traditional PM role. And the traditional PM role is very broad. So you define the vision, the strategy, and probably that materializes in a roadmap, a document that's a roadmap. You work on the requirements, the specs. You get very involved in the go-to-market. So I was doing the data sheets. I was working on the messaging for my product. I was guiding what updates we had to do in the website. I was doing webinars. A lot of stuff, also writing documents for sales and presentations for sales. That's called sales enablement, so they could sell our product. A lot of activities related to the go-to-market, the launch plans, all that. And then, you know, focus on profitability. In my case, that was not necessarily, I mean, because the product was basically the company was the product. So it was mostly the CEO responsibility. But again, you know, they wanted to make sure that our product was profitable.
And then... We changed to Scrum. We didn't change to Kanban. We changed to Scrum. So it's a process. Okay, so now we're going to introduce this new process so we can... react faster, you know, with shorter release cycles. So at the end of every sprint, we had our release, and we used monthly sprints. So we were releasing every month, and people were feeling happy about it because we could react a lot faster to what our, you know, prospects were asking so we could sign deals and that actually fueled our growth. So managed triple revenues in four years and you know we also grew as I said from 30 to 120 people. But again, they wanted to make sure that our product was profitable.
And then we changed to Scrum. We didn't change to Kanban. We changed to Scrum. So it's a process. Okay, so now we're going to introduce this new process so we can react faster with shorter release cycles. So at the end of every sprint, we had a release, and we used monthly sprints. So we were releasing every month, and people were feeling happy about it because we could react a lot faster to what our prospects were asking. So we could sign deals, and that actually fueled our growth. So we managed to triple revenues in four years, and we also grew, as I said, from 30 to 120 people.
But the problem is that when you implement Scrum, you have the role of the product owner. And the role of product owner, we didn't have product owners. We had the product manager, we had the engineering leads that were managing the projects internally. I sometimes did project management as well for some of the components in our platform. But then we have the Scrum product owner. So you product backlog, you have to write, or maybe somebody else, but anyway, somebody has, you're responsible for making sure that the user stories are written. You share the knowledge, transparency about priorities in the backlog, and who, you know, what's the content of the user stories, what they mean, so, you know, everybody in the team understands what it is, and, you know, ideally also everybody else in the organization. And you focus on maximizing value. Nothing new here. But the problem is that, so now we have these new responsibilities, and the question is how we implement the scrum, how we assign those responsibilities within the team. And what happened, and I guess it's very traditional, when we implement Agile, in our case, again, there was not, in clear startup mentality, there was no planning. So it was mostly, okay, we're going to change to Agile. We had two, three presentations. This is how it works. There is the backlog, there is the sprint, and the daily stand-ups, and that's it. We turn the lights, we turn the switch, and we switch to Agile. So anyway, it wasn't exactly that, but pretty much. And so somebody had to take the responsibilities on the product owner, the responsibilities of the product owner. And traditionally, it happens many times. This is given if there is a product manager, they say, oh, this is very costly to the product manager also. We're just going to give those tasks to him. It's more or less what the product manager is already doing. Sometimes it's given to this responsibility. It's given to engineering team, maybe a lead engineer or something.
And so this is what we ended up with. So now we combine product management and product ownership. So we have vision and strategy, very high level roadmap, et cetera. The product backlog, more tactical product backlog and prioritize for the next sprint. User stories or specs or requirements, call it whatever you want, for development. sharing the knowledge with the team and with the organization about what we're doing, go to market, again, you know, all the commercialization, which is also, you know, takes a lot of time, you know, all those webinars, sales support, et cetera, and maximizing value profitability, okay? So, and that's not necessarily a bad thing, because if one person is doing all that, there is a lot of alignment across the organization of what the product is doing, what's the messaging that you're using. So, I mean, if you can do it effectively, it's great, okay? So that's perfect. So it brings, as I said, a lot of team alignment across the organization, and it helps collaboration. Because if you have somebody that can represent customers very well inside the team,
brings ideas, problems they have, and that fosters a lot of collaboration and interaction and discussion to find great solutions for those problems. The problem we have in that is it does not scale. So as the company grows, there is just too much work to do.
So if you look at the product lifecycle, you know, these four stages, introduction, growth, maturity, and decline, I think, from personal experience, you can have one person doing both roles during the introduction phase as you are trying to find product market fit. And you can do it as well, you know, when you're maturity and going into decline, because the product is almost in maintenance mode. Okay, so there is not a lot of work and researching, you know, what new things you have to do. It's just keeping what you have there working. Maybe, you know, you're building another product, you know, to... Replace this one. However, you know, if you are in the growth phase, that doesn't work. So there is something that's not going to work. So we were, as I said, we were growing very fast. So we were in this growth phase. And, you know, I was drowning completely. There was too much work, and I was not doing anything really well.
So that's why we decided, okay, we need to transition to something else, and we need to split responsibilities somehow. We cannot have Ramon doing everything himself. And that's how we ended up with this configuration that I call the odd couple.
So we did research. We started to think, okay, how do organizations that scale and that grow split the roles? How do they share their responsibilities? And we came across the SAFE framework. And the SAFE framework distinguishes between a product manager that is more strategic and works on the roadmap and features, high-level features, maybe you could call it epics, and product owners that work on their backlog on user stories, so they decompose the features into user stories, they prioritize them, and work with the team to deliver them. There are two other roles there. I think it's called the Epic Owner and the Program Portfolio Manager, which we didn't need for our purposes and our size. So that's what we looked at. And we actually applied this for enterprise customers, or enterprise companies, sorry. But it says it's for teams that are more than 50 people. We are more than 60, so we thought, maybe it applies to us. And we read there were some product manager experts that were recommending this, like Rick Mironoff and the guys at Rally Software. They're using this. Okay, so let's try.
And so this is what we did. So we had a product manager, in this case it was me, who was doing outbound, was more outbound and market focused. So it was looking at the vision, the roadmap, high level features, the go-to-market, again, all the activities around go-to-market and self-enablement, and all those things that I explained, and profitability.
And we had a product owner that was more inbound. So it was working more with the team. And the product manager communicated, didn't communicate with the whole team directly, he communicated through the product owner.
He would pass the priorities to the product owner, and the product owner will work, okay, those are the features, I'm going to decompose them into user stories, I'm going to build the backlog. They use the stories, share the knowledge in the team, maximize value, what we saw that product owners should do. And something very important to say, and maybe, so this didn't work, by the way, I'm going to explain why, but maybe the reason why this didn't work for us is because we didn't hire anybody to play the product owner role. We had a lot of engineers, so we put an engineer to play this role. And it was the engineering manager was playing the product owner role. And that may be the reason why this thing failed for us. I'm not sure. But we're starting to see some things that we're not too good. On the positive side, now the product manager had a lot of time. I mean, I really had a lot of time. time to go talk to customers, go visit them, spend a day, a week, I will spend a whole week in the US traveling, visiting multiple customers, getting their input.
I could spend time also doing market research. We talk to analysts usually. They provide us input on what the market is saying, what they see the market is saying and they want. And in the end, it really helped me become more strategic and not to drag down into the details of the everyday work, day-to-day work.
But that has a problem. And the problem to me, and I don't think, you know, maybe again, as I said, is maybe because it was an engineer that was working in a process, in that product owner role. But I don't understand how someone that does not interact directly with the customers very regularly can represent them. I don't understand how the product owner can be a customer proxy if he's doing the proxy through the product manager. Because in that case, I saw, you know, and we had different things, I saw different things happening. In some cases, the... The product owner was using his interpretation of the understanding of the product manager of the, you know, what the customer wanted, which was not exactly the same. And in some cases, as I've done, I've made the same mistake, I make assumptions as to what the user needs. Okay, I don't have any input for this. I make a reasonable guess. Okay, but I'm a person as well, a human being. I'm sure I understand. I can, you know, I can understand. understand how they feel, and I can make my own decisions. And that brought a lot of problems, because we were bringing alignment, the product management was bringing alignment on the strategic side across the organization.
But then there were all these day-to-day decisions that the product owner was making that were not necessarily aligned with those priorities. So while we may not build something that was completely different than what was expected, all those daily decisions, we were paying a price. They were making bad decisions there. We were, you know, again, they were engineers, so maybe they would prioritize work. They saw, okay, I have these people here that don't have enough work to do, so I'm going to prioritize this task. It's an engineer task. It doesn't maybe provide any value to the outside world, but it's something that we have to do internally, so I'll prioritize that. I'll improve this feature here because I think it really bugs me down that we have this feature that is not working, but maybe in practice it was not that widely used. So there was no reason to improve it, and there were other things that could maximize value. So we had this problem of alignment in the end.
Because otherwise the product manager needs to get very involved in the day-to-day to ensure that things are aligned.
And in that case, the product owner becomes just a proxy, maybe just more of a project manager than somebody that decides priorities.
So this was not working, and so we iterated again. Okay, so we said, Dan, okay, this is not working well. We have this problem with priority. So how can we split responsibilities in a different way? And that's how we came up with this dynamic, what I call the dynamic duo configuration. We introduced a new role, which was the product marketer. Or product marketing manager. And that person took care of all the go-to-market activities. So everything I explained around the sales enablement, we can see here. So what I said about the strategy, the launch plans, sales enablement, focusing on profitability, working on pricing, supporting sales, getting input from analysts that he would bring to the team. And the product manager was focusing on vision roadmap backlog, so it was focusing on strategic and tactical work, features and user stories, the high level and also the lower level, and value and profitability. So just by moving the go-to-market activities to someone else, the product manager could be very effective at both the strategic and the tactical side of product management.
Moreover, if you think about it, the separation makes sense because the product manager is going to focus on making sure users love the product. And the product market is going to work with a different type of person. It's going to work with the buyer. And many times, in our case, That's the case. The user and the buyer are completely different people. So you have to adapt how you deal with them. It's different understanding them. It's a very different type of job. And so this is what we did. And it worked very well. So first, there was a single owner. Because something I didn't say before, when we had the product manager and the product owner, when there were questions about the product, it wasn't clear for the whole organization who they should ask. Which seems like a stupid thing, but it was a big problem. Because they would ask someone, and maybe that someone would make a decision without the other side knowing or something, if communication was not fluid. And that caused problems. Now there is a single owner for both the strategic and the tactical work.
It brings alignment across the whole organization. Again, there is just one person that has the vision. I have the steps of how to go there, not just high level, but also low level. And I can explain that to everybody so everybody understands what we're doing and how we're going to get there. So it really helped with alignment.
And then collaboration, because you are involved in the whole process, both on a strategic level and on a tactical level, you can bring the team, and we will see some improvements we're adding to the process, you can bring the engineering team closer to the customers as well, and involve them in conversations, so they also get a first-hand understanding of what customers or users need.
It has worked with us very well. And alignment between product marketing and product management is working. From my perspective, it's easy to achieve the alignment between product manager and the product owner because product management and product ownership, there are daily decisions the product owner is making that has an impact in the product. And they need to be in sync almost every day. Whereas with product marketing, the decisions are at a higher level and expand a few months. It's not that you're changing your positioning or your vision every day. It's something that is more stable. So it's easier for us, we meet once a week, it's easier for us to stay in sync on what we're doing. However, I can see that a potential issue, again, we don't have it, but I can see a potential issue between what you're marketing, what's the value you're marketing, and what's the actual value you're adding in the product. And this could be if the product marketing person has a different opinion in terms of the strategy they want to follow. And maybe they're moving their messaging, and sometimes even unconsciously, to that, they're moving their messages to that type of value proposition, whereas what the product manager is building or trying to address is something quite different.
So what's next? So now, again, for us, we're seeing this as a process of continuous improvement. We don't stop. We always try to look at it critically and see what can we do next to improve it. So the first thing we're doing is we're implementing dual track agile. And we've done this already with some... With some of the features we're building, is that we separate the learning from the delivery. And we have a discovery track where the focus is on learning, prototyping, experimenting, and finding solutions to problems that are validated. We don't have a user story that we bring to the team and then, you know, we have maybe to flesh out the details and find out if it's going to work, it's a good solution or not. No, that's not what we do. We have these cycles. Again, these cycles are not constant. It depends on whatever we're trying to learn. But we go into the cycles of building prototypes, testing them, and validating our assumptions. And in the end, we produce... These prototypes are just mockups. It's just a series of mockups that are connected, so they're interactive. You can click on them. And they are very cheap to produce, and they are super effective to show how you're addressing the actual problem. And those become our spec now. So we have that. This is what we give development together with some additional description of some details. But that's how, and there are no problems around, you know, how it looks, how it behaves, it's very clear from that description.
So in the discovery track we have this thing we call the opportunity backlog. Those are general ideas of things that we put in there that we believe are valuable, they are ranked. And in the design, the discovery track or the design sprints, we're just picking from there, discovering, trying to refine the problem, understanding the problem is a good problem to solve or not, and how much value we can produce with them, and then experimenting, building some prototypes. And then we have the deliver, the development track that is focused on the delivery. The outcome of the discovery track is getting into the backlog of development. And development works again. We continue working with Scrum, regular. We use monthly sprints, maybe a bit long, but that's what we found out that works well for us. And maybe it's because of our remote organization. And we release at the end of every sprint. This is what we're doing.
Another thing we introduce is job stories or something based on the jobs to be done concept.
We use this for the opportunity backlog. So we don't think in terms of user stories, we think in terms of job stories, which is why are people hiring your product? Why do they hire your product? What are they trying to do? So this focus is not on the specific persona, it focuses more around the context. So what is, you know, what's the context around the situation? What are the needs they're trying to address? And what are the goals? Okay, so we don't get too narrow. We don't get into the implementation of what it is, which is really trying to surface the needs, the real needs behind the problem that people have. And for that, you need to understand well the context, and you need to understand the goals. And goals, you know, it can be emotional goals. They can be, you know, more practical goals. So this is something a bit more broad, but it gives us enough insight to try to address the problem without being biased. Sometimes user stories bias towards one solution. Here we're trying to stay very open so we can experiment.
And the final thing we've introduced, and this we already have it, we introduced that, you know, it was six or nine months ago, is objectives and key results. I'm not going to get into all the details of what objectives and key results, you can look for it. It's a way to align the organization. So you define what are the business goals, and then by the company, the departments, and each individual have their own objectives and key results, or OKRs. The objective is something, you know, is a motivating objective. And the key results is how you're going to measure that you have achieved that objective. And it's supposed to be a stretch goal. So it's not, the idea is that you don't get to 100%, is that you get to 60, 70%, but that you push people. And it's great because it brings a lot of alignment. There is a lot of transparency about where are the goals that everybody in the organization and every department has. And it also helps us measure if we're moving towards that goal or not. So what we do is we have... We use just a wiki confluence to put all that information. So everybody, every team and every individual has a page. And for the individuals, we have the OKRs and we track weekly. There are tasks that we add to align to the OKRs. There are other things we're going to do. But we write down every Friday or every Monday, depending on the team, they write down the tasks that they're going to accomplish the next week. And we celebrate our accomplishments on Friday at the end of the week to make sure to see, okay, we made progress. And it really made a difference because these activities that are sometimes more strategic and maybe not so urgent, but they are very important, they used to be postponed. Now, if you have them in the OKRs, it forces people to do them. On top of that, if you're getting another team that is asking you for something, it's easier to have a discussion. No, no, no. Look at the OKRs. They were already discussed. Because they are discussed and agreed across the company. They were discussed. We agreed upon them. So I'm not going to help you now. I need to really focus on these things to make sure they get done this quarter.
And so that's basically where we are. Hope you're still alive.
And if you want to contact me, you have my email and my Twitter nickname there.
Again, I don't pretend that what I show you today is the solution to the problems you have. You have to see in your context, evaluate in your organization, the culture of your people.
Every organization is different. But I hope it gives you some ideas on things that you can try in your teams to improve their productivity, their effectiveness, and hopefully also their happiness. Thank you.