#85 Product-Centric Organizations (Portfolios, Taxonomies) with Craig Strong

BOUNDARYLESS CONVERSATIONS PODCAST - EPISODE 85

 placeholder
BOUNDARYLESS CONVERSATIONS PODCAST - EPISODE 85

#85 Product-Centric Organizations (Portfolios, Taxonomies) with Craig Strong

In this episode, we explore what a product centric organization looks like, with our guest Craig Strong. Sharing his experience from being a Global Practice Leader at AWS (Amazon Web Services), a seasoned Chief Technology & Product Officer, he helps us dive deeper into the nuances of adopting organizational designs, cultures, and practices that cater to product-customer centricity. 

A true product operating model specialist, he has helped countless startups and enterprises to modernize and evolve to become more customer-centric. From bio-mimicry to hands-on experience, learn what inspires him everyday, to design some of the most robust and adopted organization structures in the world. This podcast is just not one to miss!

 

Youtube video for this podcast is linked here.

 

 

Podcast Notes

In this insightful episode, Craig Strong, co-author of The Lean Product Lifecycle, explores the future of product-centric organizations. With over 18 years in the tech industry, Craig has worked with startups, SMEs, and global enterprises, guiding them through growth and transformation.

 

Craig shares profound insights on this podcast, emphasizing the importance of life cycles in product development and the dangers of prescribing defined frameworks. We dive into the significance of asking timely questions, what questions to ask, and the necessity of flexible frameworks that cater to the emergent needs of complex organizations. He touches upon his infamous concept of viewing taxonomies and ontologies as products, and so much more. 

 

As a Forbes Technology Council member and co-author of “The Lean Product Lifecycle”, Craig provides a blend of theoretical and practical insights on this podcast. This episode is a must-listen for those seeking clarity and inspiration in product operations and organizational design. Tune in for a highly engaging discussion with Craig Strong!

 

 

Key highlights

  • Importance of timely contextualization, innovation, and autonomy in ideas.
  • Relevance of incremental governance
  • Removal of “Rigidity of Frameworks”
  • Creating a balance between heuristics and cultural tenets of an organization
  • Complete break-down of product taxonomies – its necessity, importance, design structure etc.
  • How to build collective intelligence in organizations
  • How to use visualization tools for imagining and executing dynamic organization design

This podcast is also available on Apple PodcastsSpotifyGoogle PodcastsSoundcloud and other podcast streaming platforms.

 

 

Topics (chapters):

(00:57) Introducing Craig Strong

(07:22) Key Tenets and Artifacts of Product Centric Organizations

(13:20) Incremental Governance

(17:20) All about Product Taxonomies 

(21:18) Patterns in Taxonomies 

(23:27) Dynamism and Complexity in Organizations

(25:55) Scalability of Taxonomy

(30:15) Alternatives to P&L in Product Development Cycle

(32:11) Objectivity and Removing Bias in Development

(35:27) Innovation Theatre and Operationalizing Product Innovation

(39:57) Skin in the Game

(42:50) Hierarchy of Taxonomies

(47:29) Building a Taxonomy and Ontology that is Convenient

(56:15) Breadcrumbs and Suggestions by Craig

(59:14) Closing Points

 

 

To find out more about Craig’s work:

 

 

Other references and mentions:

 

Recorded on 18th September 2023.

Get in touch with Boundaryless:

Find out more about the show and the research at Boundaryless at https://boundaryless.io/resources/podcast

 

 

Music:

Music from Liosound / Walter Mobilio. Find his portfolio here: https://blss.io/Podcast-Music

Transcript

Simone Cicero

Hello everybody, welcome back to the Boundless Conversations podcast. On this podcast we meet pioneers, thinkers and doers and we talk about the future of business models, organizations, markets and society in this rapidly changing world. Today I’m joined by my regular co-host, my colleague at Boundaryless, Shruthi Prakash, who is joining from Indonesia. Ciao Shruthi!

 

Shruthi Prakash

Hi.

 

Simone Cicero 

Hello, great to have you here. And as you know, on this podcast, we often discuss product centricity, product centric operating models. And today we are joined by an authority in this space, Craig Strong. Hello, Craig. Nice to have you.

 

Craig Strong 

Hi, thanks for inviting me to join. Looking forward to explore this topic together.

 

Simone Cicero 

Thank you so much. Craig is a product operating model specialist. He leads a practice, a global practice, on these and other topics at AWS, Amazon Web Services. Craig has spent many of the last few years helping organizations to transform, modernize, and adopt these kinds of customer-centric and product-centric models. Craig is also the author part co-author of a book called the Lean Product Lifecycle, a book and methodology, and now we’re the winning framework for corporate innovation and innovation culture, and the portfolio of customers that Craig has been working with includes lots of very interesting companies, Fortune 500, like Sky, or Now TV, Person, Insight Software, and Hair Graves, Lensdowne. But, you know, I mean,

 

Instead of just telling people what you are up to, Craig, maybe it’s a good idea to ask you, you know, as a first question to tell us more about your professional evolution and especially, you know, I’m interested in understanding why you ended up in being so focused on product centricity, which is a so hot topic today. So I’ll leave it to you for a quick intro on your latest years.

 

Craig Strong 

Yeah.

 

Craig Strong

Yeah, thank you. Thanks for that introduction. So it’s an interesting, I guess, answer to your question. I don’t think I ended up where I am by design. I think it was an insatiable curiosity and maybe determination of why and continuous improvement. So some background, I actually started my career as a software engineer. As I started sort of going up the ranks through software engineer managing teams, I started noticing we were building a lot of features that never get used.

 

Then transferred more into Agile to get closer to the customer and sort of build in increments and learn by iterating with customer feedback. And that actually then helped me bridge into product. So then I was looking for repeatability and then how do I actually better understand customer segments, market segments and repeatability? 

 

But what happened then is I basically started realizing that when you go into larger companies, or any company to that matter, the product managers and engineers don’t build products alone. You basically have everyone, and every function essentially is building products in the organization, everyone has a role to play. So to actually then develop and scale products, you need to look at the business as a whole and the organization and culture and those things. And that’s where I determine in some extent what the product operator model is. It’s everyone working together to deliver a repeatable value to customers. And that touches on things like innovation as well, because innovation presumes that ideas come from everywhere, and you have a systematic way to bring those ideas to customers and learn and develop those things. So I ended up in that space through starting out in software engineering and then sort of migrating into wider organization leadership roles.

 

In my time at Pearson, I ended up as a VP of product lifecycle management, which was really interesting looking at products at every stage of the lifecycle and then funding models and worked with CFOs and so forth to understand, well, how do we take a venture capitalist approach in enterprises as opposed to a budgeting model for different products at different stages and those things. Yeah, and that led me to eventually join AWS and all our customers are obviously cloud driven and cloud enabled at very different stages of their adoption. But when you look at what customers are trying to do with cloud, they’re ultimately trying to drive top line or bottom line revenue or bottom line efficiency. And that brings in, well, it’s not just technology, but you have to think about how everyone works together to deliver value. And that’s again, where the product operating model comes in to maximize the value of technology in those contexts.

 

Simone Cicero 

So you managed to touch on so many interesting points just on the opening question. So for example, you said a couple of things that I want to double click on, which is fantastic. So product centricity as a way to think about the customer. That’s a very important point because sometimes large organizations end up more focused on their processes than the customer itself. So product centricity helps keep everybody accountable to the customer because product and customers are two topics, two ideas that are very much connected. Then, another thing that you mentioned that I think was very interesting, finance, the role of budgeting and you said transitioning into a VC operating model, so basically investing into ideas instead of budgeting, which is I think another fantastic point to bring up.

 

And it very much resonates with the work we are doing with Rendanheyi and the 3EO model that kind of pushed the organization to think about a venture building organization. So having said that, maybe another kind of quick question that I would like to ask you is to help us frame a bit the conversation we are having today. And maybe what I would like to ask you is to, you know, give us an overview of the key tenets or the key concepts that exist in a product centric organization. And what are the key artifacts, for example? I’m thinking of, you know, portfolios, taxonomies, you know, particular elements of the culture or structure or organizational processes.

 

Let’s try to give an overview and from this overview then we can peek into some of the deepest or you know go more vertical into some directions.

 

Craig Strong 

Sure. So you touched on a good point. So I use the phrase product operator model a lot. And what I find when I speak to customers, there’s certain phrases, product, operator model, innovation, transformation, and they mean different things to different people. So I’d like to usually define those things. So when I talk about a product, a product for me is any entity which can create repeatable value to a customer or customer segment, I should say.

 

But when I say a product operating model, I’d like to just call out a key value point and pin in that is customer centricity. Because one of the things I’m challenged with sometimes is I go into organizations, they might have a very sales centric way of working, which is sales that which doesn’t necessarily lend itself well for efficiency a lot of the time for repeatability, because it can be very short term thinking driven by incentives.

 

Similarly, when I see product, I find it challenging because I think if you look at product management for the last 10 years, it implies customer centricity. But a lot of people still see customer versus product centricity, and I don’t call that distinction. I think modern product companies are customer centric. So the value or the tenant of customer centricity is through the entire organization.

 

What that means is you know who the customers are, you work very closely with the customers and use data and feedback from customers to make objective decisions strategically and tactically. So if we were going to look at some of the tenants I suppose underpinning that, I would say, or product operator model, obviously customer centricity as I’ve just mentioned there.

 

But the other thing would be you’ve got a connected organization. So I work with customers to try to define when you’ve got the executive group, you might have a business unit and you might have a product line and then you’ve got the program level and then you’ve got the product teams. All those things are connected through aggregation and taxonomies and portfolios, which I’ll come to in a moment. And you’ve also got, you know, the notion of

 

If you’ve got customer centric metrics and a customer centric culture, you move away from projects. Projects still exist in a product world, I’m not saying they don’t exist, but at the same time they’re in the context of outcomes and that you don’t deliver projects because I believe a product is born when a project is delivered and that’s not conducive to feedback loops. So you need a connected organization, you have the cultural aspects and you need the mechanisms to be able to actually make all that work.

 

Key mechanisms for me are a portfolio, a portfolio at those levels. You have an executive company view of a portfolio. You have business unit level portfolios and you have product lines and potentially programs as well of a portfolio. But you also then need a key point is a life cycle context. So going back to what we explored earlier about funding and everything else.

 

A life cycle for me is really important because you’re able to contextualize the right questions at the right time. And if you get that wrong, you could dismiss really good ideas too early or discover you’re developing the wrong things too late. So if you put, if you cross-section a portfolio with a life cycle so you know where your products are or ideas are at different stages, you can introduce incremental governance in a way where you can maximise learning and develop a culture of learn fast and quick decision making. At the same time, I’ll stop after this one, but at the same time what’s also important there is the mechanisms of portfolio taxonomy and the life cycle provides you with objective criteria of what’s under performing, not just performing well and to free up capacity to innovate. That should give you the ability to say no quite often and to actually close things down or remove duplication from your portfolio. And that allows companies to potentially innovate without increasing spend because you’re recycling resources and recycling investment.

 

Simone Cicero

Thank you so much. I know Shruthi has a question, but I want to just highlight a few bits for our listeners and then I will leave it to you Shruthi to jump in with the question. So you said these are the tenets. You have to have a portfolio. A portfolio can be made of product lines and so the idea of a portfolio just to make it clear for our listeners is a way to look at the system of the products that you develop in your organization. So several approaches to this, but essentially, as Craig said, we’re talking about understanding product lines and products and sub products and things like that. Then you mentioned, Craig, that there needs to be an executive view, so a strategic view of this portfolio. Then you mentioned two more things. One thing is taxonomy, and this is something we’re gonna dive deeper, I think, because at the moment is one of the bigger questions that we have on our table. And then you mentioned lifecycle. And I think one thing I wanted to underline for our listeners, you said you need to have an incremental governance. So may I ask you to clarify a little bit? But what I perceive is that maybe initial projects, so products that are still in exploration phase may need lighter governance than projects that are more mature in the pipeline, am I right?

 

Craig Strong 

Yeah, that’s right. It’s also, so they have, let me give you some examples around this, I suppose, where when I go into enterprises, more often than not, to get an idea off the table, you need to write a business plan or something of that equivalent. That can be quite a substantial undertaking. The business plan requires investment and you need to do things like financial forecasting and everything else.

 

If you’re doing true innovation, you don’t really know the revenue. And anything you project on the revenue is a wild guess. But as soon as you put it in a plan, those wild guesses become, they get perceived as assertions, not assumptions. So if you put in the context of this is an idea, we’re exploring this idea. And you focus upon customer engagement. You focus upon the customer problem. You can learn about what the best business model is through that process as opposed to pre-define it in the business plan. So you might actually take months of customer discovery and customer engagement to understand if you’re really solving the problem before you even think about revenue because you know that would be too early. Now that’s not to say you don’t do any research at all because you know you wouldn’t want to go into a space where there isn’t a potential return investment because there’s obviously a cost to that exploration.

 

But you can do market research to see if this is, you know, how much, you know, what’s the category, how much people are spending in this, how, what is the customer segmentation and market look like. So there’s some indication that there is a potential return investment. You just don’t know the specifics at that time. So as you learn through the ideas, move through the different levels of a life cycle, you can start introducing more information contextually into the next stage.

 

And that also allows you to stop things. So if you’re spending a couple of months exploring an issue with a small team and you don’t meet the success criteria, you’re not solving the customer needs, fine, then that’s great. You’ve spent less time doing all that planning and you can move on to the next idea. The other thing, just to point out though, which I think is a real constraint that not too many people talk about enough is, is the notion of how alienating traditional governance can be for innovation and ideation. So what I mean by that is most companies I work with are enterprises these days and they are usually globally distributed or have quite a substantial breadth of employees across different regions. And innovation shouldn’t be made exclusive to a group of innovators or those people who are politically connected to the budget holders because that will constrain the ideas substantially.

 

So having a life cycle, which is very simple. So anyone with an idea and those closest to the customer can actually capture their idea in a very simplistic way and actually get that in the portfolio. And with support, without having to be trained in an MBA or business plans, you’re more likely to get an increased number of, increased quality and an increased number of ideas to actually explore and exploit for your future business health.

 

Simone Cicero 

Yeah, yeah, yeah. Thank you so much. Shruthi, maybe before if you don’t mind, maybe before going deeper. I think there is one thing that Craig, we should be clarifying a little for our listeners, which is what is a product taxonomy, you know, because maybe a lot of people understand what a life cycle is, what a portfolio is a portfolio, many, many products, lifecycle, the steps, you know, from exploration into more, more mature but what really is a product taxonomy?

 

Craig Strong 

Yeah, good question. So it’s quite funny actually when I talk about taxonomies and life cycles, usually people are not engaged until they realize what they are and how powerful they can be. So for me, a product taxonomy is a simplistic categorization and hierarchy of how things relate to each other. So that means you would have, as we’ve said, a customer-facing product and you might classify that as such or customer-facing platform.

 

And within that, you might have many platforms and internal products, which all make up part of that. And you might have services and everything else, which are all part of that. So it’s the hierarchical relationship between those things. And it’s really important to make that classification because when you look at a lifecycle or portfolio, you look at it from a lens or a layer of the taxonomy. And when you’ve got a taxonomy in place, let’s just say you’ve got an internal service which serves many products you’re able to look at the attribution and inheritance and the total cost of ownership with much more clarity. And you’re also able to call out dependency because if you’ve got this relationship between which services relate to which products and platforms, you can actually understand, like I said, what the cost is, what the dependency is, what the release cycles are, what the investment is, where the risk is, and what the operational structure looks like. The other thing around it is

 

I think it actually drives behavior. So as I said, it’s essential for portfolio management because you’d look at the level. But let me give you an example. So I was working with a retailer recently in the UK and I was looking over their taxonomy for and their portfolio should I say over the last 12 months and they had a taxonomy in place. But when you looked at the portfolio, there was an increase in platforms. So they had quite a lot of waste, not really much clarity on if you ask the question what does this do and what problem does it solve, it wasn’t really clear who the customers were. And there was a spike in the number of platforms over the last 12 months for some reason. When we investigated that a little bit further, the reason being is because by classifying something as a platform you could bypass a lot of the governance. So whereas a product would go through the life cycle, and you’d say, who’s the customer and what this thing. A platform in this company was an internal facing product, and you could get away with finding a lot less on those things. So it created a problem for them, because products were then being defined as platforms to get through, probably most of them were passion projects and things like that, which made it very difficult to close down and then diluted the portfolio into a meaningful artifact.

 

Simone Cicero

Just before switching to a deeper question that is coming up and session in the background, I wanted to ask you, you mentioned two things, you mentioned products and platforms, which is a common and recurring element of taxonomy. So for example, we can recognize them also in many DevOps frameworks emerging. So for example, if people listening are familiar to team topologies, there is this idea of platform teams and stream aligned teams. So we kind of see this resonance. But the question I have is more like if you want to double click into what else do you normally have in taxonomy or what are the patterns that you see more often. You know, I mean, concepts such as modules, sub products, bundles, anything else that is worth mentioning before we move into deeper considerations.

 

Craig Strong 

Yeah, so actually when I was at Pearson a few years back, we were actually implementing the product lifecycle. And we realized pretty quickly you couldn’t really implement the product lifecycle or portfolio without defining the taxonomy. And it was very difficult because Pearson at the time went through a lot of M&A and we had, you know, it was things like the Financial Times was part of their portfolio, which is very different to some of their educational businesses. But there was also the complexity, as you said, of bundles and things like that. So what we ended up doing is defining the skew, the single sellable unit, whether it’s a bundle or a separate product as the lowest common denominator for a customer facing product. And what we were able to do with that then, if you’re able to sort of say, well, this is a book, for instance, and that’s a product. This is a course which is a bundle of different things. This is a platform which sells many products. All of those are SKUs, they’re sellable items. And then you have bundles, and you’re able to sort of see the inheritance that way. You can sell this independently, or it’s part of a bundle, and that bundle can be part of a platform that way. And then you can create those relationships to know the total distribution in that form as well.

 

Shruthi Prakash

Thanks, Craig for that. I think one of the points that stood out to me as well was the fact that inherently organizations are complex and increasingly so, right, with time. So a lot of the inputs that you had said before this as well in terms of its complexity, the need for governance and so on, how does that hold true when organizations are extremely dynamic, growing in size and how do you ensure that your systems of operation are kept up to date and constantly so, how do you go about that?

 

Craig Strong 

Yeah, so it’s an interesting question. So organizations are complex and you don’t need to be a big organization to be complex. And what I think though, when I look at, you know, I work for AWS and which is obviously part of Amazon, which is a, not a small organization by any means. Um, and one of the things which works well for us to scale is we have a bunch of leadership principles and tenants which drive behavior and that gives us flexibility because, you know, our number one is customer obsession. So when we’re having debates, you know, we will default to, is it the right thing to do for the customer and that will drive some of the behavior. The important thing is we have common mechanisms and it’s not just Amazon. This is, you know, large organizations I’ve seen perform well. They have common, they have cultural tenants, which drive behavior and call each other to account.

 

You have common mechanisms, so there are ways to interface. If you’ve got an idea, this is how you submit it. If you’ve got a, this is a taxonomy and this is how things are related to each other. If you are at this stage of the product, this is how you manage it and this is what the team looks like. Or in our case, we have the notion of two pizza teams, which are small autonomous teams which have clear ownership of things. So those things hold true.

 

What I think doesn’t work and what can be a massive inhibitor is prescription of defined frameworks. Because if you try to prescribe a way of working in a too detailed fashion across a range of an organisation which has complexity, you won’t cater for the difference and cater for emergence. And I think emergence and difference are absolutely key ingredients for innovation and performance and continuous improvement to prevail. So it’s balancing, you know, using heuristics, using tenants, using mechanisms to reinforce those, the cultural tenants, but not over-prescribing the ways of working and allowing for difference. And how you do that is, you know, you can have commonality through interfaces, but you can have autonomy within teams or products behind those interfaces. That’s my observation.

 

Simone Cicero 

Craig, what role does it have in the scalability element? What role in your experience is, you know, what is the role of P&L and profit and loss and, you know, in general, wrapping finance around products and teams and also of other elements that are more about, you know, circulation of information, like visual documents or communities of practice, like rituals. So coming, you know, staying in the original question from Shruthi on how do you scale these? How do you ensure that this approach stays stable as your organization changes, you have new people coming in, you know, people go out and so on finance, P&L, and documentation, community of practice, processes, and so on.

 

Craig Strong

Yeah, so let’s dive into that. So I think there’s a cultural aspect. How do you maintain the culture and things, which, you know, higher slow, higher fast is a good way to protect the culture, but that’s not always possible if you grow in fast and all of those things. I prefer to sort of make it, focus more on, you know, drive higher the right people, hire based on principles and culture and skills are trainable. So hiring the right people and taking them on the journey and giving them the support that’s needed is absolutely essential. Support can come in the form of formal training, but also communities of practice, mentorship and coaching and all of those things which have their place. The P&L is interesting because, you know, it depends what level you’re asking the question at, I suppose. But from a, if you look at from – everything we do is to drive customer value and inherit from customer value. There is a business model. So if you, you know, if you take money as a by-product of value, then you can focus on the customer and you can work out a business model that way. Now it has to be sustainable, you know, you could, because you can have an operable business model, but it’s a business model. So the P&L, you know, you have to have minimal thresholds and things like that of what need to be in the interest of the strategic view with the company and the P&L informed strategy. But I think there’s the context aspect of the P&L as well. So, not put in financial projections too early, as we mentioned in the life cycle, but actually then having those support when it comes in, what does it look like and having the capability to inform and experiment with business models is absolutely key.

 

A challenge I see sometimes is particularly if finance is abstracted from product, you get product not necessarily from a finance background or many product managers haven’t worked closely with finance, but they then define the customer behaviors and everything else and they might not be able to sort of see the financial opportunities that could be there because there’s an abstraction to finance and vice versa. Finance are prescribing things to product or the part of the business model, but there are a few layers removed from the customer. So bringing those things together, I think, is absolutely key. And that’s where what governance for me does. Governance is not a control and mechanism. It’s an enabler to bring people together to have those meaningful conversations to drive meaningful decisions. So I think the P&L shouldn’t be a reactive aspect. It should be a very inclusive aspect, very close to product and the customer. And that’s an evolutionary relationship through the.

 

product through its life cycle. And it should also be aspects of that where mature products can look for adjacencies and drive more growth in different areas as well.

 

Simone Cicero 

And what is, sorry should I just a quick follow up, what are other indicators that you can use as alternative to P&L, for example in the early stage of development of a new product unit?

 

Craig Strong 

Yeah, so it depends on your product, I suppose, but you want to look at things like, you know, customer retention, you want to look at activation referrals, you want to look at, you know, how you’re solving the problem for the customer. I actually recently spoke to a VC on this, the startup looking to get investment, and it’s quite interesting. The advice was, don’t come to us basically pitching that you want funding. Come to us and show us that you’ve got at least 10 customers using your product on a regular basis and you’re solving that problem for them. And then we’ll talk about, you know, financing. So it was very much a, we’ll work out the business model after, but first thing we want to show us is that you’ve actually solving the customer problem. They’re frequently using the product over other alternatives and they’re highly engaged. So it’s basically demonstrating you can solve the customer problem well enough they choose your product over other alternatives.

 

Shruthi Prakash 

Right. So I think some of the words that you mentioned, I wanted to highlight and maybe, you know, question you on that as well. That one was that people, let’s say, experiment with business models, right, essentially. And the fact that increasingly so we need to be maybe inclusive and not reactive in our approach and so on. Essentially, all of this is done by people on ground. And therefore, there is ought to be some amount of bias in this process.

 

And maybe like you said, like hiring the right kind of folks and so on is something that is a step that Amazon maybe takes towards this. But do you have any other recommendations on how this process can be made objective essentially and removing any form of bias from the process? Yeah.

 

Craig Strong 

Yeah, sure. So it goes back to the lifecycle and portfolio somewhat. So just to clarify as well, so in my role in Amazon, I help customers adopt some of the mechanisms we’ve just talked about, but not Amazonian mechanisms, although they might be referenced as models. But I believe, you know, Spotify has the Spotify model, and if you’re not Spotify, find your own model. Amazon have their model. If you’re not Amazon, find your own model. Amazon didn’t use someone else’s model. You can still be inspired by and take ideas from anywhere. That doesn’t mean don’t use it, but try to evolve it and contextualize it to your business. I think to objectify the governance, one of the things which is key goes back to the product lifecycle and portfolio again is to define sort of key questions you need to ask at certain stages. So when the Pro Lifecycle book I mentioned was an example of that, where when you’re in the explore stage, which is after you’ve submitted an idea, you basically want to focus upon the customer problem, most of all. So it’s, what problem are we solving before you even build anything? And to support that, what’s been successful for me in the past is actually setting up the notion of product councils.

 

So these can be cross-functional groups where you’ll have someone from finance, you might have someone from product, you have someone from technology and architecture who come together on a bi-weekly or monthly basis to review the health of the portfolio. And then you can have hypothesis-driven design. So one of the things you need to get over is reactive governance or reactive attribution. So we’re building a product. We’re going to drive growth by X percent you hit like 8% and then you say that’s successful. But what I think for objectivity, you need to say, right, in the next quarter, we’re planning to move the needle of Y by 10%. And you should be held accountable for that 10%. Now it’s not the end of the world if you don’t hit it, but you should reason to Y. It could be the new competitor product coming out, it could be you didn’t do this, it could be you assumed something else, but you learned something else. So having a forecast hypothesis of what you’re trying to do. and how you think it will result in something. And then having the portfolio group come together to review what actually happened and look at the narrative underneath that of the why helps inform, you look at the metrics, but it also gives you context of the why to be able to make a decision. And why that’s also important is because you will be able to contextualize decisions, but make better quality decisions because you’re able to sort of observe the detail of the outcome in a more lateral way, I suppose. And that exploration can yield to improved innovation because you could also see opportunities which are not in your plans, which are learnings you might pivot towards, which could fundamentally be very different to what you started with, but are very important and great opportunities to explore.

 

Simone Cicero

Craig, what is the… you know, the question comes from a consideration that… We are used to think about innovation as something that is extremely inorganic and comes out of radical ideas and entrepreneurship. So what is the amount of operationalisation that we can achieve on something like product innovation? And as a side note to this question,

 

How do you avoid essentially this process to become just innovation theatre? And more specifically, what is the role in your experience of skin in the game in this process? You know, at Boundaries we are very much a big proponents of an approach that involves P&L from the very early stage, if not from the start, access to percentage of the profits. So how do you on one side empower teams to avoid theatre and also on the top, you know, on the layer of those that coordinate and decide, how do you improve their skin in the game in this process?

 

Craig Strong 

Yeah, good questions there. So the first thing, innovation theater. There’s a lot of opinions on this, but share in mind, a couple of things I think are important there is that any innovation you do has to be connected to a strategy. It might be an innovation thesis or strategic objective, but doing, ideating without a connection to a strategy and objective becomes, you know, or runs the risk of becoming pure exploration, pure play really, which is not always a bad thing, but it doesn’t really result in positive results as I see it. I worked with a team a few years back, there’s a whole division, and they would just experiment with Google Glass and all of those things. And I can honestly say out of probably 100 ideas they done, maybe one went to market, and it was by accident, not by design.

 

So if you’re able to connect any effort to the strategy and link it in the portfolio, as you mentioned, bring the P&L in, what is it we’re exploring, why, and how does this connect to the initiatives of the business, then you’re able to get the right support and the right context involved with it. The other thing is, I think there’s, yes, there are, if you look at personalities, there are people who are really uncomfortable with the unknown and there are people who are not comfortable with unknown and they’re much more comfortable in processes and so that means in the there’s people who are really good at the left side of the life cycle, the ideating, who are not so good at the right and vice versa. So understanding who plays where and what to their skill set is really important. So there’s a cultural aspect of recognizing that as well.

 

But I also would say that innovation is not exclusive to people with innovation in their title. You know, I think, like I said, anyone, ideas are cheap and anyone and everyone can have ideas. But at the same time, if you limit that to people with innovation in their title, you’re probably taking 99% of your opportunities away from potential opportunities. So removing the exclusivity and the elevation of reputation of I’m an innovator, I think it’s important to be able to commoditize that a bit more and allow people to lean in and get their ideas heard. And this also stems into the diversity and inclusion and all of those aspects as well. So it’s not an exclusive group of people, but it’s actually ideas from everywhere. So that’s important, I think, in terms of removing the innovation aspect.

 

What was the second question again?

 

Simone Cicero

I mean, the second question is more about how do you ensure that there is a skin in the game for everybody involved and both the entrepreneurs, the product entrepreneurs and the leaders that kind of allocate capital into this?

 

Craig Strong 

Yeah, so I think there’s a personal aspect to this as well. So there’s a lot of great ideas which started in large enterprises that never got pitched to the enterprises because they were on salaries and they get no reward for it. I think there is definitely a place for large enterprises. You know, I think if you speak to most people in roles, particularly around product and technology, they’ve probably got some side initiatives or big ideas that they’re not capitalized or not realized, but they’re thinking about them all the time. But there’s an aversion to pitch it because it’s not really what they’re doing in their day job. There’s not really a mechanism to support it and everything else. So if there was a way to incentivize people to get skin in the game as in a reward system so if they pitch something and I don’t mean like a prize system I’m on about equity in it would incentivize people to go over and above their day job and connect to it and bring their ideas forward in the in the organization they’re in then you know to be able to do that you’d need the governance to recognize it so you know could people be seconded you know could they be rewarded and given some time to explore those ideas, you know, with a smaller budget or a small team. And there would be a culture to allow that to happen. And then, you know, part of that team as well is to coach people through it. So you get people, you know, the finance and everything else would get involved early, they would work with them as a partner and kind of try to, you know, you’d have a team to basically do that.

 

There’s an aspect of skin in the game to incentivize people to pitch ideas in an organization. And there’s also the psychology of ideas are cheap, so unless you’ve got skin in the game, there’s a barrier to be able to materialize ideas because people will just be throwing things over the fences. So I think from my point of view, even when we, you know, my background as a consultant, an advisor should I say back in professional services, if I would advise or propose anything I would recommend that I would also be accountable for delivering it because then you actually live your recommendation, you’re held to account for it. So I think this skin in the game drives a responsibility which drives quality as well which is important.

 

Shruthi Prakash 

Yeah, just a point on that, Craig. So I understand that let’s say taxonomies in itself have to be hierarchical, but how do you make the process of designing these to be more inclusive, more flat? And therefore, maybe is there a good mix between achieving a top down versus bottom up development of design portfolios and taxonomies and so on?

 

Craig Strong 

Yeah. So I kind of use ontologies and taxonomies, as opposed to just hierarchical aspects. I think, you know, you need taxonomies themselves need to be managed. In the absence of, you know, them being managed, they kind of, they get defined and they get lost as an artifact and they don’t really get embedded anywhere. So if you define a taxonomy and ontologies, then you can basically – you should embed those into your culture, your recruiting, your training and everything else and the mechanism should reinforce it. Those taxonomies ontology is a version so they get embedded in all of those things. 

 

But the other thing is like anything really, I would consider, which I do, the taxonomies to be a product, which means a product has customers. So you might have owners of the product and the people would be able to manage it but you have a community and feedback mechanisms around it to evolve it. Nothing’s perfect and everything changes all the time. So even if it’s good today, it might not be good tomorrow. So that needs to be managed. So I would define taxonomies and ontologies as products with customers and treat them as such with open feedback mechanisms and loops and culture so people can contribute. The other advantage of that of course is you can build up examples and build up the depth of knowledge because you have the collective intelligence of the many that way.

 

Simone Cicero

I feel that this is a really critical point of the conversation when you said taxonomies and ontologies have to be products. So let’s recall a little bit why we in complex portfolios want to have taxonomies and ontologies. And ontologies means essentially teams sharing a certain description of the domain they are dealing with. Let’s say for example you have an agricultural company, you may want to agree on what’s a farmer, what’s a product, produce, what is transport and so on. So that the teams can develop different pieces of the product together and then these pieces can more easily connect. And I think the fact that you said taxonomies and ontologists need to be seen as products, this is fantastic from my point of view because I remember having a conversation on this very podcast with Alberto Brandolini, one of the most important experts on domain driven design. And he said, agreeing has a cost.

 

So we should be avoiding it if not strictly needed. So there is this kind of continuous dynamic between imposing a taxonomy and ontology on your product portfolio from the top and looking into what’s emerging and also to kind of add some complexity, we can talk about the role of ecosystems. So again, I wanna quote another conversation I had on this podcast with Scott Brinker from HubSpot, where he talked to us about how HubSpot is product scope, let’s say is divided into hubs, and then you have a product approach to product development that it doesn’t really pushes the whole portfolio to the customer, but rather, makes a portfolio products that are easy to connect with. So either as a plugin, as an app, or maybe you can just use the same data format. And so what is your experience as working with customers in terms of how do you build a taxonomy and an ontology that is convenient enough to be used? And also if you can double click a little bit into building open-ended products, which also have a possibility for external parties to plug into.

 

Craig Strong

Yeah, so there’s a lot to unpack in there. So for me, if you look at the good place to start for me is basically the portfolio. So when you’re looking at products across a portfolio, you need to have an objectivity to be able to see like for like. How do things compare of the similar type? And that’s really important because unless you’ve got that definition, you can’t really see you can’t really manage a portfolio. You need to be able to sort of see objectively what those things and how they compare. And then you wanna drill down, you wanna drill down into those things and you wanna see those relationships as we mentioned. So it’s absolutely critical to basically define that. And that’s usually a good place to start, what do we wanna see in our portfolio? And let’s define that one level and then you start drilling down, well, what products or platforms or services or modules might actually plug into that and what’s the relationship and how do they interface in that way. You might not want to manage modules at a portfolio level. But the other thing why that’s really important, particularly in enterprise is, we’re talking about innovation, but one of the biggest consumer for me is waste in terms of innovation potential. It’s not like a lack of revenue. It’s actually waste. Waste is in duplication or underperformance. I’ve gone into many companies and they’ve gone through lots of M&A. I’ve seen 50 ERPs internally for companies. The cost of getting information out is so high and they’re so abstracted, you can’t really make decisions so you start seeing the secondary symptoms of those causes as you start putting the taxonomy in. The other thing there is, you know, when you look at, you know, if you want to externalize that, I think there’s a distinction between an external and an internal, because you, I would put a taxonomy into the, starting at what’s the customer face in product, and internally you would have that as the P&L, the group of the P&L, so the P&L might be product line, it might be a business unit, but then there you’d have maybe a product line or products, and the products could be platforms or not, depending how you define that. But you’ve got that inheritance and relationship. When you go to external points of view, like you mentioned HubSpot or so forth, the whole point there is to actually create those interfaces and attributes and structures for people to be able to operate. So if you have a platform and a platform can you can pull in content, you can pull in modules, you can extend it with apps, you can pull in or develop APIs and everything else. Those are actually interfaces and those interfaces have rules. So it’s really important that you define and version those things because there’s an ecosystem related to those interfaces that needs to be managed when things change. And there’s a relationship of inheritance which actually comes in from different definitions as well. So the failure to actually manage that well is really expensive in terms of cognitive load on the users and the customers, which is something you want to avoid. When you get that really well done, then it becomes instinctive. An example, I don’t know if this is helping answer the question, but I believe that we’re all inherent taxonomists. So if you’ve got children, I’ve got a young daughter, one of the first things you teach them is about animals, you know, because you’re looking around and they’ve got a curiosity of the natural world. This is a bird, this is a dog, this is a cat, and then there’s different types of birds. Well, that’s a taxonomy. And if you think of, to demonstrate how well we are, how well we inherit that we are of taxonomies, I’d challenge anyone to go to a supermarket.

 

So when you go to a supermarket, guess what? You go to the grocery section, and everything’s there with the groceries. You know, you go to the vegetables. You might go to the bread section. You might go to the dairy section. You might go to the frozen section. That’s a taxonomy. And no one thinks about that as a customer, but you can go into every store with a rough consistency of every store set up that way, and you can navigate to find the products you want very quickly and exit the store. So there’s an inherent taxonomy in that. And that’s the same when you talk about with digital products or other products, you wanna make it so instinctive and so simple and so consistent that you’re actually, no one has to think too much about it and it becomes almost obvious. But at the same time, you wanna optimize it like a product. Like if we use the supermarket example, they’ve got flows through the store, which actually maximize the checkout experience and the buyer, the total cost or the value per customer through the journey, through the store, through that taxonomy. So you want to think about that as well in terms of how simple you can make it for people to connect, how natural and intuitive inheritance is, and how well you can objectify the governance and make those comparisons so you can then monitor performance.

 

Simone Cicero 

You have a quick thing that I wanted to double click and then leave it to maybe lead us through the closing of this conversation, but I think I’m getting this strong signal from your side that everything you drive into either a platform, sorry, a portfolio strategy or you know, your API strategy, your extendability products, the sensibility strategy needs to be convenient from the perspective of both the third party, the customer and so on. So I think that this is a very strong signal and something to chew up on and to think through as designers in terms of, you know, sometimes we talk about those standards, we want to position our products as pivotal in the ecosystem, but the question is, is this convenient?

 

So there needs to be a strong convenience in pushing up some kind of taxonomy or structure or modularity or kind of language or whatever, because otherwise systems won’t really agree on something because there is an implicit cost on agreeing on something. So if there is not implicitly, sorry, an explicit maybe benefit of doing it, it’s going to be very hard for both for teams internally or customers to… is this capturing what you’re trying to say?

 

Craig Strong 

Yeah, absolutely. And that’s why I mentioned managing those things as products as well, because it’s about the value. I think it’s essential, whatever you introduce, governance and taxonomy could be seen as governance. But what is it you’re trying to solve and how do you do that in a way which minimizes it? And it could be a taxonomy, it could be trying to solve clarity in the portfolio, so you’ve got objectivity.

 

It could also be so everyone knows where they are in the system and how they connect to other people in the system so they can see themselves within the system. But you need to make that as simple and inherent and instinctive as possible because the if you think of it this way, the absence of it increases complexity or even a state of chaos potentially. But once you have it, things can operate more in a fluid manner.

 

So I mentioned earlier, you know, Amazon’s a large company and we have, you know, cultural tenants and we have mechanisms and we don’t have prescriptive frameworks in many ways because we use interfaces as small teams. So we know quite well how, you know, what, which team owns what and how they, and how to interface with every team is very clear. Who makes decisions is very clear because we have single threaded leadership.

 

So it’s very clear where you go if you’ve got an issue or if you need something, who can help you and how you can interface with those things. I think when you’re scaling, that’s essential, otherwise you’re gonna be increasing cognitive load and complexity substantially.

 

Shruthi Prakash

Thanks, Craig. So I think this helps us also get a rounded opinion on how to approach building and implementing taxonomies, right? Is there maybe something we missed touching upon from our side that you’d like to probably highlight for our listeners? Or if not, you can also share maybe some breadcrumbs or suggestions as we call it from our side for maybe books or podcasts that have inspired your journey as well.

 

Craig Strong 

Yeah, I’ve enjoyed the conversation. So I hope we’ve covered a lot of things, I think, well in what we’ve explored. I guess what I would share is one of the things I find, I draw my inspiration from. Although I’m kind of in a product and technology world is biomimicry. So when I, when I look at sort of teams, for instance, and the structure of teams.

 

I try to actually, I read a lot of biology and biomimicry and I draw inspiration maybe because it’s abstract from resources outside the field. So if you look at like a cell, you know, a cell is pretty consistent in size. When, you know, if you go through meiosis or mitosis, the cell splits and it creates another cell the same size. I liken that to how you create teams. You have, in Amazon, we have two pizza teams. When the team gets too big, we split the team into another thing. So they roughly stay the same size and then there’s common interfaces. So I like to draw a lot of inspiration from biology. Taxonomies, this might be too much information, but I love actually going through the history of biological taxonomies, Carl Linneas and people like that, because it’s quite interesting when you look at the natural world, how they look at taxonomy as an over time, as we’ve kind of got more advanced in DNA and things like that, how it’s challenged some of the taxonomies and then how it’s used. So I always find that quite important. I’m not expecting everyone to share my passion on that. But if you’re interested in taxonomies, I would strongly suggest looking at the biological structures and biology as a prerequisite there. The other things around, you know, there’s, you know, I draw a great inspiration from, you know, product conferences and leadership conferences. I try to actually go to different sort of fields. One of the things I try to do is avoid going to the same types of conferences all the time. So I might go to financial conferences, HR conferences, not just technology conferences, because it gives me different perspectives. I’m able to engage with different functions and empathize with the challenges they have and build bridges in different domain languages.

 

Yeah, I can follow up with some links if that’s of use to anyone on the readers, but that’s where I draw my inspiration from.

 

Simone Cicero 

Thank you so much. Your link will be welcome. And this also leads me to say that our listeners will be able to check the show notes on boundaryless.io/resources/podcast where they will find your episode and the others that we have been running in the last four years now. So check the show notes. And yeah, I mean, that was a great conversation I think overall we touched upon so many great topics. And I want to just double-click in the last thing you said, this biomimicry perspective. It’s really interesting, you know, and I started to think through ideas like product species and symbiosis between products instead of bundles and ecosystem of products with maybe some leading species and the others. So it’s really, really very interesting also to see how you can entertain both pragmatic approach, like when you said think taxonomies and ontologies as products and on the other side, keeping this complexity mindset in your work. 

 

So thank you so much for sharing both of these kind of energies in the conversation. So thank you so much, Shruthi, it was great to have you on the podcast.

 

Thank you, thanks. Simone, and thank you, Craig, for joining us today. It was great talking to you.

 

Craig Strong 

So thanks for inviting me. I really enjoyed it.

 

Simone Cicero

And again, yes, thank you so much, Craig. It was great to have you. And I mean, for our listeners, until we speak again, remember to think Boundaryless.