Part - 2
This is the second article in a three-part series on product management, the new paradigm in agile product development. The first part discussed the necessity of better product management and how to start leveling up your product management practices. This second part will focus on the cultural aspects that separate the highly successful digital product companies from organizations still in the earlier stages of their agile product development journey. The third part of this series will discuss ways to measure success and keep track of whether you are providing value for your customers and your business.
Why isn’t Agile delivering us the results we expected?
The issue with Agile is that it has become one of the most broadly misunderstood concepts in the professional world. We want easy answers, and the simple promises of copy-paste methodologies are too tempting to pass, compared to the long and tedious cultural shift required to properly adopt the principles that make some of the most successful companies in the world thrive.
Let’s compare two teams as an example:
- Follows Scrum routines by the book
- Has a Scrum Master and a CSPO certified Product Owner...but..
- Works with a long backlog collected from different stakeholders, and has difficulty showing the impact of infrequent deliveries
- Doesn’t believe in Agile processes
- Has no Scrum routines or roles...but...
- Is empowered and able to solve problems for customers, delivering measurable impact frequently
Which of these teams would you consider more Agile? To me, it’s clearly team B, as it’s the only empowered product team here. Team A focuses on methodologies instead of value, and is potentially a frustrated feature factory with a long and scattered backlog.
Don’t get me wrong – processes and routines have their place and purpose, but the point is that they are by no means the silver bullet for replicating success. Routines should be crafted based on a set of first principles (more on these later in this article) and serve where the organization wants to be on the scale of innovation vs. predictability.
Are you focusing on the process or the content?
In The Lost Interview with Steve Jobs from 1995 – just a short while after he was forced out of Apple and was in charge of NeXT computer – he reflects on the successes and hardships at Apple, saying:
“When companies start to get bigger, they want to replicate the initial success and a lot of them think, well, somehow there’s some magic in the process of how that success was created, so they start to institutionalize the process across the company. And before very long people get very confused that the process is the content. But it’s content that makes great products, not the process.”
Why is this dangerous? Over time, a lot of things in companies become folklore; they are a certain way because they were that way yesterday. That’s when process becomes the substitute for thinking – if people do everything by the process, they can’t be blamed for the missing impact of their work. We think we can lead complexity and scale with processes – but what rigid processes really give us is just a false sense of control.
How to lead complexity, if not with processes and methodologies?
A healthy culture heals broken process. The elements of a healthy culture include:
- A set of first principles. Keep reading, I’ll list some examples of first principles shortly.
- Thinking. Think deeply about product strategy, focus on genuine product discovery, provide well thought-out guidance on big product and policy decisions.
- Talking. Ensure sufficient coaching for your teams and individuals, talk relentlessly about your first principles, and inspirationally about the strategic context.
The culture of any high-performing product company will be built on a set of first principles, or basic propositions and assumptions that can’t be broken down any further. The following list of first principles is here to give you and idea of what you should be aiming for. It is not comprehensive, nor are the themes ever so black and white. There are nuances in applying these in any organization, and the changes should be done based on justified thought, fitting in the context of your organization.
Here are some examples of first principles collected from some of the most successful product organisations in the world:
- Focus on people. First, please let’s stop talking about people as resources. They are human beings with their great characteristics and odd flaws. They have great weeks when they thrive, and they have bad ones. When you ensure people feel trusted and have an environment of psychological safety at work, they tend to gladly go above and beyond for their work community, not only delivering their best work but also contributing to the shared healthy culture. Remember, words are not enough to create psychological safety – the care for people needs to be shown through actions, and it should shine through in every interaction within the organization.
- Vision and guidance. “Make Spotify the best place to discover music,” as stated by Spotify’s product leaders, gave a clear mission and purpose for all the teams that they could focus and obsess over. Teams need leadership and guidance, however autonomous they are. As Avid Larizadeh Duggan puts it: “A leader should articulate what needs to be done and why, and then let the product team decide how to best build it.” To be explicit, monthly priority presentations for the department are not enough – you need storytelling on a weekly basis to remind what is most important, and to keep motivation up.
- Love the problem. Do you really know what are the most crucial problems for you to solve for your customers? If not, be open about it, go get the data and involve your customers. Do you know how to solve those problems? If not, real product discovery is needed. If you think you already know the answers, but don’t have the data and customer insights to back it up, you may be 1) solving the wrong problems or 2) solving the right problems in a way that has no traction with the customers. Keep the feedback loops short with customers, other teams and stakeholders by working transparently and exposing incomplete work, and you’ll reveal shortcomings faster.
- Outcomes over outputs. Outcomes matter, and for example the velocity of a team is not an outcome. And neither is whether a project is delivered on time or not. If the needle doesn’t move – there’s no desired change in your customers’ behaviour – what use was the project, even if it was on time and budget? Give your teams targets as concrete outcomes, and let them figure out how to get there. Like many other things in this list, this is easier said than done. Often the changes in customer behavior can only be measured in business metrics (e.g. market share, customer retention, etc.), and you – or the managers/coaches in your organization – may need to help the teams to remember this is about the customers; helping them solve problems and make their lives better. Worthy of a separate mention – maintain your focus. Having seventeen high priorities means having no priorities. Read more: Project vs. product
- Trust over control. Empower your teams to make decisions, and you’ll become much faster at delivering value. The teams are closest to the customer (or at least should be), and they will just spend excessive time summarizing and waiting for decisions if they don’t have the permission to do them. “We need a team of missionaries, not mercenaries,” as John Doerr said it. The more micromanagement, the less you get out of the people working in your organization. You surely hire smart people, so why not trust them to do great work when given the space to do so? Give the teams autonomy, yet ensure high alignment on the common direction and outcome targets. Emphasize that autonomy comes with responsibility and accountability – as each team owns their decisions, they also own their results and their part of the company’s success..
- Empower engineers. I want to separate this from the previous item as it’s so important. Your engineers are likely some of the most capable problem-solvers in your organization. If you only want them to deliver code at the highest possible velocity, you’re only getting half of their value. Give the problems to the engineers to chew, enable direct collaboration with customers, designers and stakeholders. You’ll soon see value delivery ramp up, not to mention the people being more motivated.
- Loosely coupled, tightly aligned teams. Depending on the legacy in your organization this may take some time, but aim for minimal dependencies across the teams, and enable them to move fast and autonomously. Yet, leadership, transparency and communication are vital for the teams to pull in the same direction.
- Continuous improvement and adaptation. If you want to move fast, things will break. Don’t assign blame, just learn and move on. Showing genuinely, time and time again, that only learning and continuous improvement matter and failing is okay (as long as it comes with the expectation that you learn from it) will encourage quick adaptation, innovation and autonomy in the organization. As the racing legend Mario Andretti famously said: ”If everything is under control, you’re going too slow.”
- Cross-pollination over standardization. An important part of your teams’ autonomy is their freedom to choose the methods, routines and tools they use. Yet, by allowing teams to share what has worked well for them, others may get great ideas and apply them in their own work. Yes, in some cases it may be good to follow the “golden path” of recommended tools and routines that are proven to provide good alignment between the teams – but exploring other routes should always be welcomed.
Summary and caveats
As with anything related to a cultural shift, the ideas in this post are not silver bullets that can be applied everywhere. Successful change requires you to involve the teams and people (not a nice-to-have, but a must-have), and start experimenting incrementally. It’s not the easiest of journeys, but can be one of the most rewarding ones you can find yourself on. My great Futurice colleagues and I are happy to help you navigate this journey on your side.
- Timo HalonenAgile Organization Coach