I’m joining OCTO. Great adventure. Lots of curiosity. Full of opportunities.

Conversations are starting up, about product management. I’d like to share a conversation that just began, with pleasure. It allows me to clarify a sort of professional statement of faith on product, product management.

I’m being asked:

Her - “We can talk about the cloud as a business accelerator, it’s certainly a reality, but it’s been around for a long time (Airbnb, Netflix, Engie, everyone does it). Not everyone is there, but there are few unknowns about the opportunities to accelerate. The real topic is the creation of new business models, that’s where the real opportunities are being played out today. I have plenty of examples, starting with the 3 giants who, after becoming infrastructure then service providers, are now marketplaces for others to sell their softwares. They get paid through this (fees between 3 and 20%), a new business model that’s growing in their revenues. It’s an opportunity for everyone. Banks for fraud prevention for example, AWS did it recently while banks were watching each other, they could have released a fraud prevention service/platform. How not to miss the opportunity, is this what a product company is? And if so, what’s the path?”

Me - I’d want to start from this article by John Cutler: the product system.

First conclusion (article from 2017): we can no longer think about product in a linear way. There’s so much happening in the market that the product must constantly listen to what’s unfolding, and know how to react, adapt¹. These notions of emergence, adaptation, everyone knows them. But who really applies them? Not as many people as that. We should start there.

And the article I’m referring to highlights an important dichotomy: “there’s product, and there’s the organization made for the product”². Thus, and I’m convinced of it, no product without a product organization.

So what’s the path?

I believe we must start by questioning ourselves. Too often we observe the supremacy of the delivery solution. We build, we deliver, we build, we deliver, like Shadoks who pump without knowing why anymore. We must question ourselves. For example, I regularly hear “we put into production every two weeks”. I imagine this highlights a guarantee of technical excellence, but we can’t stop there. First, why put into production every two weeks? Is the rhythm right? What does the client want? What serves us? And then: when we put into production we have the impression that we’ve reached the end when it’s precisely the beginning! What goes into production, what becomes of it? Who uses it? How?

The first step is to implement a whole system for collecting learning about what happens with our products, feedback. (little by little, let’s not dive back into a big heavy process that isn’t end-to-end, and without emergence, a big up front). In the article I’m taking as a starting point, this importance of feedback is highlighted. We talk about the importance of improving the understanding and collection of feedback, but also of enriching the fineness of its reading and the data that comes to us.

There’s therefore truly a conversation that changes in the company. We question ourselves first about the reception of our product, the complexity of the context in which it evolves, the competition, the needs, etc., and we question ourselves next about how. All the gaze is projected outward and not inward. It’s often hard for companies that have become political (end-of-life cycle stated by Mintzberg) and whose questions only turn inward (What will become of me? How to climb the ladder? How not to be at fault? How to respond internally?). And if there’s something to build, it’s this tool for receiving and collecting feedback (but it too constantly evolves).

The second step (concurrent or not, it depends on the context) is to be able to reorganize ourselves to deliver the product, in a product approach. The idea is to have a capacity to deliver an impact, outcomes, influence (to try more French words) on our market. For this we must adhere to the so-called agile principles of response to complexity: end-to-end teams that know how to regularly deliver autonomous pieces of product that we can put in users’ hands to validate or invalidate them. The stronger the capacity to change, modulate, quickly validate our hypotheses, the more flexibility we’ll have, the more performant we’ll be, because our product grows, invents itself, or feeds on this learning, these constant loops of fabrication, observation, adaptation, and discovery.

This path therefore acts on the organization’s structure, because having end-to-end teams is not easy when this hasn’t been the case for several years or decades. It’s also very difficult to give enough autonomy to these teams so they can feel free enough to make all these hypotheses, to constantly test the market to find the paths. The cloud you mention is a simplification tool to test and carry all these products and the hypotheses they constantly carry. My conviction is that one way or another we must give control back to end-to-end product teams, from idea to production deployment (it’s up to organizations to secure their infrastructures and their deployment flows accordingly).

So a reorganization of teams, making available to teams an end-to-end framework, an awareness of the importance of feedback, constant learning, and constant observation of what’s happening with my product and around it.

This reorganization is potentially as constant as the turbulences of the market on which we operate. It can shake things up, but it also brings positive things, this famous resilience (once again this topic is addressed in the cited article).

This general flexibility, this agility, must be well understood, it must be culturally integrated. The path I suggest is that of real options.

I think a very good source on this matter is Chris Matts, here’s one of his articles (in English, real-options-enhance-agility).

I’ll allow myself to translate a few excerpts here (well, I ask deepl):

For any decision to be made, there are three categories of possible decisions: a “good decision”, a “bad decision” and “no decision”. Most people think there are only two: either you’re right or you’re wrong. Since we normally don’t know what the right or wrong decision is, the optimal decision is actually “no decision”, as it defers commitment until we have more information to make a more informed decision.

However, if we observe most people’s behavior, we find that an aversion to uncertainty causes people to make decisions early. Real options address this aversion to uncertainty by defining the exact date or conditions to be met before making the decision. Instead of saying “not yet”, the real options approach says “Make the decision when…..”. This gives people certainty about when the decision will be made and, consequently, they’re more comfortable delaying the decision. Delaying commitments gives decision-makers greater flexibility, as they continue to have options. It allows them to manage risk/uncertainty by using their options.

This is the “decide as late as possible” from Lean, “at the last responsible moment”.

The benefits of real options are on the one hand to give ourselves time, granularity and therefore flexibility, and secondly it again highlights the question of learning, observation, feedback. Before responding: let’s observe, learn, until the next decision.

In your example about banks I don’t know what was missing. It could be the absence of looking outward and that all that matters now is how I’m going to personally get by, within the organization. As in so-called political organizations (à la Mintzberg). So perhaps no one was receptive to this external stake: competition and the interest of a market on fraud issues. It could be the absence of understanding emergence in this uncertain world, of flexibility, no one was capable (except Amazon therefore) of triggering a device light enough and end-to-end: to learn, to test, to make hypotheses and discover that a product was missing (and that they had everything in hand to respond to it).

Does this answer your question?

Her - I retain the product org, even though you don’t describe it.

Me - A product organization is an organization that’s designed to deliver something that can be used. Well, that doesn’t differ a priori from all organizations. And indeed I’ve omitted the essential: an organization composed of sets, and each set possesses an autonomous element that makes sense, and as such can be delivered end-to-end.

To better understand what we’re looking for, it’s best to explain that “before”, organizations were (or still are) composed of teams based on expertise, which provide components. For example the graphic charter team, the data storage team, the banking calculations team, etc. The problem when you want to travel light to learn quickly from your market when you need to call on all these teams it becomes a chore. And to coordinate on a calendar, it’s hell, the slowest one always wins. And also, everyone works in their corner on what they think is relevant, but when you bring it all together it’s a bit like exquisite corpses.

So to have this product approach, which means building while listening to everything happening around us and seizing all the possibilities to amplify value, we started thinking in dedicated feature teams. I’m the team responsible for the search engine for example, and whenever I want I can update the search engine, include new things, remove things concerning it. Or I’m the “user club” team, etc. There are always cross-functional teams (“the graphic charter”, “encryption components”, etc.), but they’re at the service and must propose to other functional teams to exploit and use as they wish what they expose. The “search engine” team comes to pick and respect the rules of the “graphic charter” team, but in no case should it wait or be blocked. All technological evolutions go in this direction: microservices, docker/kubernetes, cloud, etc. we’re looking for autonomy within the whole.

The latest movement is to go toward “impacts teams”, teams dedicated to impacts. It’s one more layer. Components at the service of feature teams, feature teams at the service of impact-dedicated teams. The reason? We can consider improving the search engine, or banking algorithms, we’ve given autonomy to teams, but it can remain fragmented in the approach. It’s up to product managers, heads of products, strategists to give coherence to all these teams, however this can have limits. And each advancing team doesn’t as easily see the whole. So we’re turning toward impact-dedicated teams. They’re in charge of delivering an impact, which will probably be composed of modification, work, on a set of features, on a journey. In any case we’re giving ourselves even more freedom: we can touch everything. And we mirror what we’re looking for: we build the team according to the need.

There can be a game of musical chairs: frequent change in team composition which brings advantages and disadvantages. Like a mixed assembly of component teams at the service of functional teams at the service of or that let impact teams come into their domain when necessary. And this requires advanced technology that authorizes this flexibility. Like a sculptor who may well have all the best ideas in the world, their material must allow them the implementation.

Her - I hear the notion of fast feedback. But thus, delivering often = having feedback often (even if it’s to test hypotheses) right?

Yes we tell ourselves that if we deliver often, or rapidly from the beginning of fabrication, we’ll regularly or rapidly have learning, measurements, we’ll quickly and/or regularly emerge from our hypotheses to move forward. It’s true. But I hear too often “we must deliver every two weeks” as a senseless mantra. We must at minimum question “why?”, and thus at minimum measure: delivering without measuring impact can quickly not make sense (unless it’s to validate technical feasibility). Delivering to deliver doesn’t make sense. Delivering to measure, learn, create value (to be validated), that makes sense.

And yes if you deliver every month you take the risk of being wrong for a month. If you deliver every two weeks you take the risk of being wrong for two weeks. It’s better. (Remember the risk-taking of projects for a year or more…). It must remain relevant for the service, the user, the use to which it responds. And we must be careful that the pressure induced by the most regular delivery possible (we’re talking about two weeks, we could deliver every day) doesn’t destabilize teams.

My point of view is that with time and technical expertise the goal to reach isn’t to tell ourselves we can deliver very regularly (every two weeks, every day, etc.), but that we can deliver as soon as it makes sense. The technique, the expertise of “delivering” has become a commodity that in no way blocks the business decision on the sense of delivering. We deliver when it makes sense. And so yes if there are very regular modifications and we want to benefit from them and learn as soon as possible, we deliver regularly and as soon as possible. But it doesn’t always make sense. So, let’s not reverse things: we need a fluid tool that allows us to no longer bother wondering when we need to deliver and if we can deliver. We must be able to deliver when we want. Regularity bringing a guarantee of solidity and quality.

Me - I retain autonomous end-to-end teams on the whole product until its availability to users and feedback.

Yes that’s what I was explaining above.

Her- “It’s up to organizations to secure these infrastructures”, to these teams you mean, right?

Me - I mean that these teams must have the faculty to be able to work all the way to customers, to the use of what they develop. And that the work of security teams, infra, IT, is to make available to them (in large structures, in small ones yes they do everything) all the infrastructure available (and up to standards). And especially that these IT, infra, security teams feel very much at the service of product fabrication, they must remain uncompromising on their quality criteria, but this shouldn’t slow down or hinder operational handling by the team that’s building. We avoid changing actors: when suddenly it’s another team that’s at the controls for production deployment, it breaks all the dynamics, all the commitment. The product team carries it to usage (production deployment and user handling), the other teams make available the tools and ways of doing things.

Her - hmm, it’s clear indeed. I see a huge amount of agile and lean startup principles indeed. For my part, I think precisely that “traditional” companies ask themselves way too many questions before launching. Basically, when you’re Amazon, when you have infrastructure and services, teams that are well organized and understand how to do things fast and well, it doesn’t cost very much to launch and see. When you’re a “traditional” company, launching a “hypothesis test” like that, knowing that nothing is organized (infra, services, devOps, etc.) to do things fast and well, it can cost so much time and money and resources (and other projects they don’t do instead) that they don’t launch into it. Combined with this “no right to error otherwise I lose my position” story so inward and personal gaze, well bingo, even if you see the opportunity, you don’t go for it… Basically, you can do product as you say, if you’re comfortable organizationally AND technically to do things fast and well. Accelerate: speed conditions excellence. What do you think?

Me - I completely agree. You cite Amazon. Bezos (whether we like him or not) had pounded his fist on the table and ordered all teams to expose an API, that is to say to allow dialogue at all times with each team that lets all the others come exploit its services. He freed the organization from many technical constraints thus. Yes it takes managerial courage, or healthy panic, to trigger these projects. Which in my eyes also isn’t resolved in “big bang”, but over time.

Her - What I mean by they ask themselves too many questions, is that digging into the need, seeing their target, etc. I think these are organizations that spend way too much time doing this. The message also behind delivering every 2 weeks, is to go toward agility, it all depends where we’re coming from.

Me - We’re all somewhat shaped by a Cartesian idea that everything can be planned, calculated, thought through. We forget too easily: a) that everything constantly changes and therefore that each reflection becomes extremely rapidly obsolete, b) that things are much more complex and it’s impossible to think of everything. Thus in our world reflection feeds on emergence, and therefore on action in the field. We try, we observe, we learn (I’m citing a bit the cynefin thinking model). We’d gain enormous time by first trying THEN starting to think. But we really have brakes on this: others’ gaze, the idea that thought is superior to action, etc. There was a quote I believe from the president of Linkedin who said: if you’re happy with your product when you release it, it’s because you’re releasing it too late. It’s a very good indicator, even if it’s not valid for all environments (as always). Let’s allow ourselves to be surprised.

Her - Another point that seems essential to me: You can test when you know how to stop a service/product. There’s a concept called the Google services graveyard. And it’s very full. Not knowing how to kill a product with dignity is also a brake on launching them. But when you know how to do things fast and well, launch several and manage indicators well particularly usage, well you can kill them it doesn’t matter, you move on quickly to something else. Know how to abort :)

Me - Yes once again I could cite Linkedin, supposedly 85% of what they released disappeared, because they saw it wasn’t working. It’s a beautiful form of maturity to know how to remove things. It’s a sign that we’re really interested in our product and the associated experience.

The conversation continues with pleasure.