CPO Series: Leading the Transformation From Projects to Outcomes

Read the Full Transcript

The following transcript has been altered for readability. 

Spiros Theodossiou: I’m really excited to talk to everyone today at the CPO Series.

And I know we’re going to be breaking towards the end for some additional Q&A. I’ve been doing product for over 20 years. First, 10 years were mostly in digital certificates. The past 10 years have been mostly in payments in the UK. And then more recently, I joined an inside portfolio company called Dex and we do SAS software for counting firms. But you know, when I started doing product management 20-odd years ago, I came from engineering and moved to technology where you can interact with people understand markets, and things on this black and white plus was a really bad developer.

And I love tech, I love how tech changes the world we live in. Then I moved into product management. Initially, I did a lot of work on complicated product requirement documents, marketing, and common documents. And then kind of went through the whole agile revolution of well. So I’ve kind of seen it all from really old-school waterfall product management to Agile.

And at the end of the day, what it comes down to, is how you work closely with your dev team. So I’m going to start off with a slightly controversial statement that hopefully doesn’t turn you all off. But I think the way I should have classified this is why Agile does not work by itself. Because Agile is a great way to take customer input, react, respond, etc, to what’s going on in the market. But the problem with a lot of that is if you keep reacting and changing, you never get things done.

There are two things I always say. If any company, at least a software company wants to sustain competitive advantage, there are these two key things that I always talk about.

As a company, you have to understand your customer needs better than your competitors. Because if you can understand their needs, you can predict what they want. And this doesn’t just mean asking them for what they want, giving them what they want, actually understanding the needs, what they actually need from the solution. If you can understand that better than your competitors, you’re in a perfect position to deliver what customers need to interact with you on an ongoing basis.

The second piece is how do you make sure that you develop and deliver the features faster than any of your competitors can. Or at least fast enough so that your customers can use those features as they need to? If you can do those two things, I firmly believe that you can retain your competitive advantage. Doing those two things is slightly trickier. How do you get your teams to work really quickly work really fast? There are cultural issues, there are timezone differences, you know, product and takeaways on potentially two different sides. I’m a big fan of believing product and engineering are two sides of the same coin. However, they each bring different perspectives on what needs to be done.

So how do I think the magic actually happens? There are three key areas of focus in any company that I ever work with work at. The first one at the top is people. And I don’t just mean you know, good people tend to people, etc. It’s about the structure of the organization. This enables people to do really good work that doesn’t have any bottlenecks. Because if the organizational structure causes people to invite causes people to compete for resources, and they’re wasting their time on stuff like that, they’re not actually spending their time effectively building products that customers love.

So getting the structure is absolutely key. And that’s where I want to spend a lot of my time on. I’m allergic to projects. I’m allergic to projects for a few reasons. One primarily is because no one ever hits the dates. Either you hit the date without half the features, or you complete the run over the date and things are way too expensive. Projects just don’t work.

Now, the other big thing is how you figure out what the right products are that you want to deliver. That’s why customer input is key. I’m a huge fan of Jay Christensen. If any of you have not seen Jay Christensen, the perfect multitrack video, I highly recommend it. What is the problem that you’re trying to solve for the customer? How do you make sure that your teams are moving in the right direction? That’s typically how product and tech, in my opinion, can deliver it efficiently and effectively.

So how have I evolved my ways of working, and how I’ve structured product and tech teams over time to be effective, I’m gonna give a few examples. I’m a huge fan of it.

The Importance of Value Streams

I’m gonna call them value streams, different people call them different things. But basically, what value streams are, it’s a group of engineers, a product manager, and a designer, it could be one or two of those groups, or it could be three or four of those groups. But they’ve all got a common mission. And I’ll get into that in a sec. But if I start on the left, my big problem with the project is time sensitive resource always drives the wrong behavior. You are often trying to get something done before those resources disappear. This means you are making the wrong trade-offs for the customer, and you will never build value for customers. If you focus on the short term, people and teams build great value when they’re focused on building something for the long term.

The teams that are closest to the customers are the teams that understand what customers need. And if you only if they’ve only got resources for a short amount of time, they’re not going to optimize for customers, they’re going to optimize to deliver on the project. And that’s the key thing. You never delight customers by building a single feature. If we could, we’d all be out of jobs, we have to constantly build new features and new products for our customers because the markets evolving, customer needs are evolving, and technology is evolving.

Now, I’m a big fan of Daniel Pink’s book on drive. It says for people to be happy in their jobs, they need three things. They need autonomy, mastery, and purpose. And if you can give your product and dev teams and designers those three things, that for me is really where things start getting together, and beautiful things start happening.

There’s a really interesting HBR article called The Power of Hidden Teams. And the example that I want to give you all is, they did this analysis, it was actually in a hospital where they looked at two different scenarios, the one hospital had a team of nurses, and a team of doctors. Every day, the nurses work with a different set of doctors depending on the shift. So patients always get different nurses, and doctors always work with different types of nurses.

And they kind of measured the effectiveness of patient care. And then they did something different. Another hospital said, this isn’t quite working. What we’re going to do is we’re going to form squads, doctors, nurses, and physios that actually focused on a few patients. And what happened in this scenario, the nurses, the doctors, and the physios were all much, much happier in their jobs, they all started doing a much better job, because they also respected one another skill set that much better. Whenever we work with diverse teams, those diverse teams are what bring enrichment and make us better at the jobs that we do. And this for me is why it’s really important that you create value streams.

If you’ve got a value stream, which is comprised of developers and product managers and designers, if that team feels more aligned to their value stream than they do to the dev team into the product team, that diverse concoction of teams working together, that’s what drives the best outcome. Because there are fewer handoffs between siloed functions. The other big thing is that with big teams there’s a really long-term view of how those teams work on solving the patient problem in the nurse example or solving technical problems. Also quality and productivity go up when people focus on one area. So now moving to the right-hand side, I’m going to call these things value streams. Now Scaled Agile, does some really interesting work on planning increments, value streams, etc.

And depending on the size of the org, in a scaled agile can sometimes be a little bit too bureaucratic. Create value streams focused on customer value. That is key. Now depending on the size of the organization, you could have three or four value streams.

When I was previously at a payments company Paysafe we actually had four different value streams, one focus on consumer, one on merchant, one on API’s and one on platform and why I find that really important is, once you’ve created those value streams, the teams have a mission, which gives them their purpose. Once they’ve got the mission, the other big thing that the teams have got is they’ve got those teams dedicated for a long period of time, which means if they’re in the middle of a sprint, or you know, four weeks into sprint and figure out, are we building the wrong feature, we actually need to pivot and tank somewhere else. They don’t need to get resources approved to go work on that. They’re close to the customer, they can pivot in the value stream themselves to get that work done.

And the biggest challenge teams typically have is if you need to justify the resources you need for a project, you spend way too much time putting business cases etc, together. And at the end of the day, it’s not about business cases, your dev product capacity is pretty set in stone. Yes, it can move up and down.

It’s about the opportunity cost, How do you make sure that your teams are working on the most important thing? So as a Chief Product Officer, if you can basically delegate how much investment you want to put in different parts of your business, as I said, I can a marketplace, consumer merchant platform, and you make those decisions for your product managers, all of a sudden, the product managers in the dev teams know how much capacity they’ve got, they know how many resources they’ve got. And they can start running really, really quickly.

And then you need to make sure that the tech and the dependencies between the value streams is reduced. That typically is what drives the autonomy in the teams. And that’s when you’re ready, start getting teams that understand the domain space really well, because they’re working on it for a long period of time. teams that work really quickly and well together because they understand one another really well. And teams that understand the resources. So the types of processes are put in place, each value stream could be comprised of one to three dev teams, you can have more or fewer, depending on the size of the company.

But when I forces, every planning increment, planning increments can be quarterly, that can be every six weeks, each value stream needs to evaluate what are what is the prioritized backlog you need to look at what is above the line or below the line. I’m sure as product managers, we’re all used to backlogs. But I’m not a fan of a single backlog for an entire organization. Because what happens in those situations, how does a product manager trade off a merchant-facing feature versus a customer support improvement versus a platform improvement? But by making those decisions and delegating the benefits down to the value stream level, all of a sudden, all that product manager needs to that value stream needs to worry about is what are the things we think we can deliver in the next planning increment.

Additionally, Chief Product Officers should look at what is not going to be delivered in the next planning increments. And that’s how you set expectations with the rest of the organization around. These are the things we’re doing in the next six to 12 weeks. These are the things we’re not doing. And typically when you can communicate what you’re not doing, and what are the things above the line I priority, the rest of the organization doesn’t get scared. And they don’t want to push the item forward because they don’t know when it’s actually going to be delivered.

So huge, huge fan of value streams, how do you create value streams? Really, really difficult. If you create the wrong value streams, and there’s too much interaction between the teams that causes conflicts. Someone once described value streams to me as cutting a piece of wood. If you try to cut the piece of wood against the grain, it becomes really choppy, it becomes really difficult. If however, you cut the teams along the right value stream, all of a sudden, the teams can work as independently as possible with as few interactions.

So creating the right value streams takes a huge amount of time and effort from the CPO, the CTO the exact teams working on that. But once you’ve defined those value streams, you know, ideally you want to allocate capital, a number of resources, etc, on an annual basis so that the teams know how long those go. Within the year, you can absolutely move one or two developers between those different teams. But as long as the majority of that capacity isn’t actually changing over time, that is typically what gives people the confidence to make the long-term decisions and benefits that get the right outcome for customers.

The last slide I’m going to mention with you is there are a few things you know over time that that influence you that kind of drive the decisions that you make, as I said Scaled Agile, has some really interesting learnings. They’re a huge fan of big room planning where each value stream actually needs to work through where are the interdependencies for the next planning increment. Huge fan of the shaper box. Huge fan of version one of Marty Kagan’s inspired book version two Arthur was a robot high-level huge fan of Clay Christensen and everything he actually writes specifically it’s the four-minute video on the perfect milkshake highly, highly right commended.

Obviously, the Agile Manifesto is something I look at all the time, just to remind me what’s going on the value chain, I’m a huge fan of the strategize a work, where they basically look at this value prop canvas, which is like a one-pager that talks about the value of the product. But then for those of you that have never used Jeff Payton’s user story mapping.

For me, it’s such a brilliant tool, because you basically map out the entire customer journey, and you don’t build down in terms of going deep into any part of the customer journey, you basically build horizontally. So you build the entire customer journey, and you prioritize the features that you want to release in each of those journeys. And that’s where value stream has become really important, which is, once a team’s got ownership over a customer journey, then they just defined the increments with which they want to improve that over time. So these are some of the things that inspire me. Hopefully, what I’ve shared today resonates and makes sense. And I think I’m up with my presentation, but happy to take any questions from anyone on the team and help Sydney.

Kalei White: Thank you Spiros! We already have a bunch of questions. Let’s start with what differentiates a good chief product officer from a great Chief Product Officer.

Spiros Theodossiou: Yeah, it’s a great question. I mean, at the end of the day, it’s how you delight the customers. And is the business growing in the right way?

And for me, that comes back to how you create the right culture in the teams because no matter how good a CPR is, well, we need to build this feature, and it’s gonna solve the problem, or, you know, we need to get ready faster delivery, if you can create the right culture that allows teams to get the customer feedback, and deliver products really, really quickly.

For me, that’s what makes a great CPR, which is getting the culture right within r&d. Because once your dev and product managers are a team alone in the US cooking with gas, the rest of the organization really comes along because you start getting more predictable in terms of when things are going to be released, the sales and customer support team stopped getting frustrated that it’s taking so long in there no visibility. So the transparency that comes with speed is typically what I think drives a great Chief Product Officer to help a company grow and delight customers.

Kalei White: Totally culture. I mean, if your employees aren’t happy, then you’re not going to get the outcomes, right?

Spiros Theodossiou: Absolutely. They’re not focused on the right thing if they’re fighting for resources all the time.

Kalei White: And that leads to the next question. So how should a Chief Product Officer think about, you know, capacity and resources?

Spiros Theodossiou: The hardest job up front coming into any new company is how much capacity you need and what needs to get delivered. And as I said, not a fan of a single agile roadmap. But for me, if you create the right value streams, and you typically allocate a certain amount of capacity, a certain amount of resource per each value stream, when you do your planning, you can see how much capacity each value stream has to deliver the stuff that you need.

But more importantly, you see how many good things are below the line that you’re not actually delivering on because you don’t even have the capacity. And that, for me is the key thing. Because once you start getting visibility in what you can’t deliver, that helps you as a CPL, justify to your investors, to your co2, CFO, there’s all this good stuff that we’re not doing. Because we don’t have enough capacity. There are multiple things you can do in those situations, you can take resources from another one of the value streams, and you can ask for more resources.

Additionally, what sometimes happens is once you allocate the work to the different value streams, you’ll see that some value streams aren’t necessarily delivering as much value as before. They’re constantly focused on bug fixes instead of driving new creative things. So that transparency into what teams aren’t doing, at least gives me the visibility into well, where where are they good ideas? And where is the value coming from? And then how do you start putting your bets in? But if you try and do that on a project basis, where you’ve got, I don’t know 50 100 Things in a big backlog, it’s really difficult to allocate resources to that one thing and then reallocate it to another piece.

So value streams helps you as a CPL, figure out where the investment in the business needs to happen, as well as if you need to kind of bring your costs back down. How do you take the cost back down? The analogy for me is sales teams and industries or countries. How many salespeople do you need in a particular industry or particular country to get the revenue growth that you need?

And for me, that’s about how you create the right value streams, which is someone that speaks Italian or English is not going to sell any Italy or the UK. It’s having the right skill sets that focus on the right thing. And understanding that capacity and being able to justify the return that that investment drives. And the last thing I’ll say about value streams is each value stream has an annual cost. Each value stream is delivering features that deliver revenue and growth over the next one to three years. All of a sudden, you can start defining your ROI at a value stream level, as opposed to at a project level. And that just makes the conversation around investment that much simpler and that much easier if you’re talking about investment in areas of the business instead of investment across 50 different projects.

Kalei White: Great. And you mentioned that the value stream design does not work well if there are too many dependencies. So how might you go about managing and tracking those?

Spiros Theodossiou: Yeah, so part of the wooded analogy is, if you create the right value streams that are focused on a great piece of customer value, typically the customer dependencies are, are reduced. So it’s really key to spend time understanding, you know, like, on a marketplace, merchant versus consumers is a really good analogy, because there shouldn’t be as much dependency across those two areas, where the problems come in, in the technology stack when you’re touching the same technology stack or, or touching the same platform. And what’s really important is, ideally, you have your value streams plan, they work independently.

But then when you go into the next planning increment, which is okay, for the next six weeks or next 12 weeks, we need to make sure we understand the dependencies so that we can hit our goal, how you track those dependencies is typically what the big room planning dates. So you get those value streams together, they talk about all the things they’re going to deliver. And they kind of say, oh, for this particular item, I actually need a little bit of the consumer roadmap to kind of expose this feature, I’m building into the merchant side. So being able to have those conversations upfront so that when you get into the penny increments, everyone knows what the expectations are.

If you have value streams that are constantly interacting and have too many dependencies, you have to recreate the value streams, because then you don’t have that autonomy and independence. Right. And over time, you sometimes need to pull the technology stacks apart.

Kalei White: Shifting gears a little bit, let’s talk about metrics. So in today’s market, the role of the Chief Product Officer in the context of business is very different than like let’s say 10 years ago, what KPIs if any, should the value stream and product org, in general, be using?

Spiros Theodossiou: Yeah, I mean, a lot of quite specific to different businesses. Absolutely customer-client engagement, NPS is huge. And I don’t just mean your general customer, NPS, or product-specific NPS. There are some really basic things there around customer focus NPS, your CSAT scores, etc.

But for me, the really interesting one is where there’s much more of a focus, especially as investment starts laying down, etc. It’s return on investment, which is how much optics capital are you spending on each value stream. And where is the return actually coming from? It’s really difficult in product to kind of have a quarterly return or a return within six months. Yes, there’s stuff you can do about onboarding flows, etc, about getting more engagement, typically, those are all great features that you can introduce but really see the significant return on the investment from a business case point of view, you typically need a six to 12 to 24-month window.

The key thing is how you measure the return that you get on the investment because when you go to your board, or when you go to the investors about the incremental investment you want to make or the savings that you need to make in the business, it’s really important to talk about the ROI on the investment that you’re making because anyone putting money into a business wants to see that the money is being used efficiently to get a higher return.

And a lot more of our time as CPAs is actually spent working with the CFO, the CEO, and the board to figure out what is the right level of investment needed for the growth of the business and what is the right level of investment to ensure that the business is going to grow the way it needs to grow.

And as CPOE you have to be having those conversations around investment and return and it’s not easy, but it’s impossible to do it when you’re doing it on a project base period was breaking the law into easiest-to-justify chunks around where the value is created, that typically drives a much easier simpler conversation around how you justify the return you’re getting in a particular area. Because each value stream has got a set of OKRs, or KPIs that you can measure against, it’s much easier to have the conversation run over the long term, this particular investment is driving these types of outcomes for the business. That’s, that’s something that resonates with CFOs. And in boards,

Kalei White: We are almost out of time. But I want to ask you one more question. And it’s about product ops. What is your opinion on, you know, the value of product ops?

Spiros Theodossiou: Product ops is such a critical function to the way I work, which is how teams do their planning, how teams document things, what tools teams use, and how often teams do their planning. Basically, all of the machinery or infrastructure around how product and dev teams run.

For me, that is the role of products. The only way you can get the effective use of your product and dev teams is by having the function of a really strong product that actually drives the cadence within the organization, and drives the consistency across the different teams in terms of how they track and measure things efficiently and effectively.

Because if you don’t have all your stories in a single tool like a Dragonboat-type tool, you won’t have visibility into where your resources are being allocated consistently, and over time, there’s no way to actually drive those improvements. So products are all about a consistent way of measuring the effectiveness of the teams and driving that continual improvement.