Moving away from the Monolith — faster, better with a product mindset
Understanding the core value of what you are working on is the secret to delivering impactful products.
This article has been updated since its original posting, and I’ve also published a second part to the article titled, Building a product oriented team?
Not that long ago I asked a team member what he was working on. “I was assigned some authentication tasks,” he replied. I was tempted to dive into how that kind of agile worked (or didn’t), but stayed on topic and rephrased my question. “Ok, got it. Why is this feature important right now?”
Basically, his answer was, “Beats me. Ask the product owner.”
To understand the context, you need a little background. I was doing a waste walk exercise with the team — trying to find out how much of the team’s effort was going into the wrong things. We wanted to discover wasted effort and uncover opportunities to improve team performance.
From his answer, you can probably guess things were a bit waterfall on this project. People worked in their niche, as specialists, with upstream and downstream activities being more or less opaque. In some cases the boundaries were stark, like when the development team passed a build downstream to the testing team. Not entirely, but more or less like this:
We were working at a conservative financial institution. Despite everyone mouthing agile terminology, we weren’t very agile. They had put some lipstick on the pig by naming a few things with agile-sounding names, and hiring a “scrum master” (who was really a project manager that balanced Gantt charts and assigned tasks). We still had waterfall, but it was actually unhealthy waterfall — because everyone was pretending it was agile.
What’s wrong with waterfall?
First off, I want to be absolutely clear there is nothing “wrong” with traditional, waterfall style project delivery. It meets certain criteria very well (and other criteria very poorly). Do I want my medical services or launch vehicle team using an agile, fail-fast fail-first approach? Probably not.
And likewise, I don’t really want my financial institution to embrace “daily deployment, feature flag driven, community tested” agile development. That works great for social media, not so great for my bank account integrity.
But there is a middle ground, and definitely room for improvement on this project.
Here we were, a sequential, siloed organization. The “product owners” were essentially upstream experts that came up with features, wrote them down as requirements, and passed them to the architects. The resulting design specifications flowed downstream to the development team, sometimes losing a lot of context and detail that had come from the original planning.
The development team then built the technical implementation. But now we are two or three layers removed from the source, from the “customer value.” Sometimes what the team built was misaligned from the original intent. And then their work, the developed software, moved further downstream to the quality assurance team, for testing. And it kept on going, to security and operations, and ultimately into production. Nobody had a real understanding of the whole.
The whole thing took six months and when you asked anyone “why is this specific feature you’re working on valuable,” most often nobody really knew. Most likely, they didn’t know because the customer and the business goals were far removed from the day-to-day work.
This is how the bank viewed product development:
It’s kind of like that “telephone game” that we played as kids.
There are multiple players (silos) involved, and each one does a specific thing. These “silos” of expertise focus in one area: Creating an architecture, or testing a finished product.
Information is relayed from one silo to the next using many different, disparate artifacts like requirements documents, architectural designs, and functional and technical designs.
Each silo plucks the artifact they need, such as a technical specification, out of the collection and works on it.
No silo has a complete picture of the product. Each only has deep knowledge of its own narrow slice of work.
Everything is coordinated across these silos by imposing orchestration, most often in the form of project management.
The root of the problem is that each silo is very good at one thing — but very poor at understanding the whole. “Can’t see the forest through the trees” is an apt metaphor.
Now that you have some context, I want to talk about a better way. About shifting to a product oriented organization.
Being product oriented
What if we turn things on their head a bit? How about building a team that has a complete understanding of the product, and all the skills to build it? Everything, from customer needs, to design, delivery, and even operations?
Building a team like this begs the question, how do you scale? How could we have one team that understands a product so thoroughly without building a ridiculously massive team? We need to break the problem down, make it smaller. But rather than breaking it down by creating narrow, deeply specialized silos, we break the product down into smaller pieces. Each part of the product becomes a smaller “whole” — a sufficient chunk of customer value that can be delivered as a unit, and understood completely by a small team.
In our financial institution case, that looks like building “mini-products.” Rather than a single massive monolith to handle all of the customer accounts, transactions types, and financial controls we create isolated services. One service handles customer information. Another one handles identity management and authentication. Another, simple transactions, and yet others for basic accounts, trades, loans, and fraud prevention. Each is a fully functional application by itself, but each is also narrowly specialized.
Now we can align a team around delivering an entire segment of customer value from concept to operations — for example, we now have a “customer accounts team,” and a “fraud prevention team.” It might look a bit like this:
We’ve transformed the shape of the organization to make it product oriented:
Each team has all the necessary expertise to finish their product, including customer representation, business analysis, technical implementation, quality assurance, and DevSecOps skills.
The team operates as a whole, on the entire product from ideation to delivery.
As a product-focused team, the team understands the entirety of their product, from the basic customer value premise all the way to how to deploy and operate it.
Customer value is delivered entirely by the team, creating ownership, deep expertise and knowledge about the product, and efficiency.
The product mindset
Leading companies — typically digital natives — have adopted a product mindset to drive close collaboration between the business domain experts, architects, developers and delivery teams. The advantage is rapid iteration to create and capture customer value. The most successful digital native companies are very good at it — picking up on evolving customer needs, quickly delivering new value, and adjusting and iterating.
They do this not by measuring the project but instead measuring value delivered into the customer’s hands. The team as a whole focuses on the customer value, not the technical outcome of their work. It uplifts the overall knowledge and understanding of each team.
Individuals are no longer isolated specialists but instead become part of a dedicated team that owns their product end-to-end. The team deeply understands customer needs and knows how to deliver. They become highly collaborative and focused on realizing customer needs.
A product mindset is embraced by the entire team and organization. It means shifting focus in the way we work. Key indicators of a product mindset include:
A cross-discipline team that is fully empowered to deliver a business outcome.
The team must have business / domain expertise, design, architecture, engineering, and delivery (e.g., “DevSecOps”) as part of a durable team.
Products and features are discovered and validated with customers. This is done with rapid prototypes and MVPs prior to delivering a “finished,” scaled-up product. User-centered design is part of the process.
Product-minded teams reserve a seat at the table for technical team members when discussing a product’s future, rather than reserving this role only for Product Owners and business stakeholders.
A product mindset is not achieved by just adopting a few new processes, changing some labels, or putting a couple of people into new roles (just like we can’t become agile by calling a project manager a scrum master).
These are a few attributes that are not part of creating a product mindset:
Waiting for requirements. If the team has to go back to the business and wait for business requirements, they are not empowered.
Not involving technical team members in product decisioning. Technicians can see around corners and provide guidance by identifying new opportunities, dreaming the “art of the possible,” and avoiding obstacles.
Creating business-facing roles. Merely creating a role called “Product Manager” or “Product Owner” to work with the development team (but not addressing organizational issues) will leave silos and separation entrenched.
Doing DevOps or Agile. Both are valuable but neither is a product mindset.
Having a slide that says “Product over Project.” Stating the goal is not achieving the goal.
Claiming to be outcome driven, data driven, agile, lean, a “2-pizza team,” or any other catchy cliché. Achieving any of these may be suitable to a variety of purposes, but they don’t define the product mindset.
What success looks like
A successful product oriented team is empowered to achieve the product vision, without external dependencies. They’ve got the capacity and knowledge to meet customer-oriented goals — meaning, get features the customer cares about into the customer’s hands.
They can also move at speed. They aren’t inhibited by upstream or downstream processes that slow them down. They can find the answers they need, and solve the problems they face.
The team is responsible. It’s their product going into production, and they’re highly aware of its success and evolution over time. That means being hands on during operations, observing the product behavior, and taking long-term interest in it.
Probably most important, the team understands the product that they are delivering. They know why it matters to their customer, they understand the value it has in their business, and they are tightly tuned-in to delivering that value to the customer.
What about waterfall?
Having a product mindset is only tangentially related to whether a project is waterfall, agile, or something else. Having a product mindset is not the same as following a development methodology.
It’s about creating teams that are invested in their product, have deeper knowledge about a product, and take responsibility for the entire product delivery lifecycle. In some ways, it’s a natural fit for waterfall — because it is essentially about creating a long-lived investment in a product.
It may require changing the way we think of building software. Moving, for instance, to a microservice oriented architecture so that teams can wholly embrace their scope of the product. But these are technical details that can be executed with any methodology.
The benefits are worth it.
If you liked this article be sure to check out Building a product oriented team, where I write about a Product Mindset team composition and “ways of working.”