The 4 Principles of the Product Organisation
What does a high velocity, customer value driven organisation look like, both from a product and technology point of view? There are four principles that guide how we should organise our functions to enable the kind of high velocity delivery described in What drives software value?
Principle 1: Product Value drives Priority.
Within a given backlog, how do you determine what is most important to do next? Using your usual sprint planning tools and IOTA in a dialogue across the full team, the only sure measure of what matters most relates to the value you anticipate delivering to your customer. In hypothesis based design we formulate an hypothesis as to the form that value might take in the software we build and every sprint we test and refine that hypothesis.
Other considerations such as the complexity of the work to be done come after this. And may cause us to refine it. However, once we have a clear view as to the next big issue to test and the software that needs to be written to test it, that refinement will likely be a reduction of scope (a narrowing of function) rather than a fundamental revision of what we think is important. We test that theory only when we release.
Taken at a higher level, how should an organisation decide to release its funds? Rather than arbitrary planning meetings where we guess at next years projects, a product organisation looks at the return it expects from a product and the investment it is willing to make in generating that return. That does not mean that in planning we cannot talk about our ideas and visions for the product. We certainly need to do so, but in full awareness that this vision is contingent. Contingent on the feedback we receive when we release. Every product should have a near term big idea (say three months out) that creates an ‘event’ for customers. What will make your customer go, “Holy Sh*t! I can do that!?”. I sometimes call this a “high stakes message” (HSM) to the customer. It’s high stakes because its a big bet you’re making and its directed at the customer. This can be structured as a story spine in the user story mapping process or used within the IOTA model.
I am often amazed at the complexity of so-called BAU backlogs. These are backlogs of small changes to existing applications, that usually are not urgent (otherwise they would be dealt with in emergency change procedures) but nice to have. Looking across a full product’s work in progress we often see the silo’s of operations, development and product management curating their own requirements. However, if both the big idea and the hypothesis for the next sprint are clear, why would you work on anything that doesn’t support that work as directly as possible? Where a support team’s sole function is to support, we will find work for them to do, whether it adds value or not. The collapsing of these teams into a single product team where all work on improving the product from a commonly prioritised backlog is the only way to prevent waste of this sort.
A common question asked is, “what about technical work that is too big to deliver in one sprint, or which cannot possibly show customer value every 2 week sprint?” The process of deciding what matters to your HSM will lead you to do work that does not release in one sprint but prepares for future releases. Examples of this could include the upgrade of package software, the implementation of a new messaging capability shared with other product systems etc. However, this work needs to be layered under the two weekly discipline of at least showing the customer regular value every two weeks. As with ‘BAU’ trivia, this technical road laying will be prioritised in the light of both the HSM and the value to be delivered / hypotheses to be validated this sprint. So what does this mean for structure?
Split your organisation into products with well defined market objectives and align all the skills you need under those products to deliver against those objectives. Bonuses, salaries, pizza, software costs etc. All come out of the investment allocated to each product. The granularity of the products should be set at a level that a single product owner can actively engage with a team and understand sufficient detail to advise on priority. A product owner may run across multiple teams working on her product but she will be in command of the detail on the economics of the features being developed, the capability of the teams to meet the objectives and the relative priority of the work remaining to be done.
You don’t have to do this in one fell swoop. Pick one product, or even a feature set and align resources around it, growing the extent of independence over time, fuelled by the success of the team. The team’s success buys its independence and its independence creates opportunity for directly partaking in the wealth that a product’s success brings. Use the ideas in ELSA to sustain the change.
Principle 2: Platforms deliver Promises.
Mark Burgess, the founder of CFEngine, developed an approach to modelling systems called, “promise theory”. A good introduction can be found in an introduction to promise theory. A promise is a ‘strongly stated intention that may or may not come to pass.’ So we design systems that make explicit promises to their consumers but we also design for the case when that promise is not kept. We do this with the understanding that knowledge of whether a promise is kept (e.g. A message is received and I promise that it will result in another system action) does not require knowledge of the internal workings of the system itself. So within an ecosystem or architecture, something needs to know whether a promise has been kept or not, enable its remediation if not and isolate the consumer, whenever possible, from this broken promise. Knowledge of the promise and its status is the basis of operation.
Conceptually, this is the same idea we apply when we deliver a product ‘promise’ to market. In just the same way that a system’s consumer is interested in the outcome (the promise) so the customer is interested in the application of what we deliver, not its theory. We use iteration at velocity to remediate those releases where we have not met our customer’s expectation. In fact, all of agile is really about being able to close this loop as fast as possible and also to assume that in general we will not get it exactly right every release.
Large systems, such as core banking platforms, ESB’s (shudder) etc. Are seldom designed in this way — neither actively remediating broken promises nor enabling high velocity iteration. In most organisations there will be some systems that support many functions across many products. So how do we ensure these systems are stable, secure and enable product velocity? It seems foolish to have completely different teams each working on some shared function independent of other users either potentially impacted by these changes or equally interested in them for their own purposes. However, the history of Centres of Excellence — often created to provide support for these shared systems — is that they become remote from the consumers they seek to serve and tend to over specify or over engineer the services they build in expectation of future demand. Centres of Excellence are very rarely excellent for long.
For those systems that provide significant support to multiple products, and on which roadmap those products are heavily dependent, establish a platform team. This team is responsible for describing and delivering the promises that the shared system makes to its product consumers. However, instead of creating a centralised function, allocate resources from that team to those product teams that make use of the shared system. This becomes a ‘home team’ for those experts in the platform. As demand for changes ebbs and flows these experts may change teams, but in every case, discussion across the platform team of the work that needs to be done is held in a healthy tension with the priorities driven by the home teams and their short and medium term goals. The experts in the platform team are incentivised to deliver the customer product first and foremost.
But what ensures that the organisation is going to invest in the necessary but largely customer invisible upgrades and maintenance that these kinds of systems need? The answer is that the platform functions like a product. It has a backlog that is distributed across various home teams in negotiation with their product owners. However, it also has a price. In the same way we charge a customer for a service, the platform charges the product for its service — this might be the licensing cost of the software, run costs etc. The platform experts, for the duration of their time in a product team, are fully charged to that team and essentially align to it completely. The secret here is that the only labour that a product team has to pay for from a platform is labour done in its team. This ensures that platform experts do not get pulled out of teams and centralised and then charged back from the ivory tower of centralisation. A platform owner, is a product owner for that platform and is responsible for the promises the platform makes, as well as the coordination of the backlog with the various product teams and especially the platform experts within them. This kind of deep embedding of platform experts into product teams ensures that product owners have good visibility of the actual impact the system work will have for them (e.g. Compliance etc.) and also takes responsibility for its implementation within their sprints.
Principle 3: Practices develop People
Platform resources have similar skills. But they may not be in the same profession per se. A platform team might include engineers, architects, business analysts etc. While they are fully embedded in a product team and essentially act to sell and implement the functionality of the platform, they still need someone to take care of their careers.
Practises are collections of resources with common skills, backgrounds and career aspirations. Practise leaders are people managers and want to be. Their focus is on the support and development of their reports within the framework of the profession of those reports. The day to day instructions of their staff are given by the product teams but they are responsible for being another line of escalation should there be a problem in a product team.
Practise leaders also facilitate the sharing of knowledge across the practise and guide in the development of the practise as a profession within the company. A good example here is the practice of Architecture. An architecture practise leader, who could be called the Chief Architect, could facilitate a discussion about how to drive standards within a specific tool set, e.g. Development tools. Based on interaction within the teams, talk about the costs associated with non standardisation etc. He may reach a decision that some standardisation is needed. The only way he would be able to implement the standard however is through the influence of the architects in the teams… any other way and we find what so often happens today, people working around the standard or actively working against it. As before, product value drives priority. Another example could be helping the practice agree on a common approach to setting the architecture vision for a product team — sometimes consistency is a good thing.
Principle 4: The Product Owner applies the 2 Product Principle.
So the only person who cares about people’s development is the Practise leader, right? Of course not. Everyone in a product owner role is responsible for the improvement of their team over time. As explained in IOTA the Two Product Principle holds that we are always shipping two products, one to our customers and one internally — think of it as the service we sell to our company as a whole, why employ this group of people to deliver these features rather than another team?
The two product principle is an implicit contract between the product owner and her team. We will invest in the development of efficiencies in the team, some of which may be personal productivity savers like new laptops, and some of which will be accelerators like time spent on creating automated tests, but this is in exchange for meeting short term objectives, I.e. Shipping quality software. The only person who can apply the 2 product principle is the product owner and her team. Nobody from outside a team can enforce what ‘product 2’ should look like to that team.
The application of these 4 principles yields a structure that looks like diagram 1 below. It is not dissimilar from other approaches, such as that originally implemented at Spotify, using squads, tribes, chapters etc. Whatever naming you use, ensure that product drives every priority conversation.