Strong product people

It's hard to get better if you don't know what better looks like

The product leader

A product leader leads the product managers building ships (products). They hire the best shipbuilders, create a proper environment for building ships, and they provide their people with the support and tools they need to do great work. The ships your teams build can only be as good as the shipyard that produces them.

The product manager's job

It's the product manager's job to come up with a product solution that is valuable to the user, usable by the user, buildable by your engineering team, and still viable from a business perspective. It's all about finding a balance between these four dimensions.

Again, what's the job you said!?

  • Go out there and listen to your users and customers to understand their problems and how you can possible solve them.
  • Conduct several experiments and prototypes to test your assumptions and various solutions before building them (to minimize the risk of building the wrong thing in a beautiful way).
  • Maximize value but minimize the effort to build the actual solution and make sure the winning solutions can be built by the team in a reasonable amount of time.
  • Deliver the product and optimize (or even innovate on) it based on feedback.

By this definition, a product manager is not a person who only collect requirements, write concepts, and maintain a backlog without making any decisions.

Do you know what better looks like?

If you don't know what makes a good product manager, how do you make sure your product managers know what they are expected to do? How do you hire the right person? How do you show them their necessary areas of personal growth?

Help your product managers understand what you think makes a good product manager. Help them identify their gaps to see what they should get better at, and help them understand what better really looks like.

Product vision, product strategy, goals and principles

For some organizations, product vision, strategy, goals and principles are very scary things - so much so that they avoid creating some or all of them. People think that it's a complicated and difficult process.

In fact, it's all about decision making. These things provide the guardrails for making decisions and prioritizations faster, and better. You need that, because there will always be more work than there is capacity to do it.

How can I grow and learn as a product manager?

  • I can learn by consuming books, podcasts, blogs, conference talks.
  • I can apply what I have consumed and learned to my daily work.
  • I can reflect and get feedback on what I have applied.
  • I can contribute back to the community and my colleagues by showing up at events to share my experiences, teach others, write articles, onboard new product managers, and become a mentor.

"Strong Product People" by Petra Wille

How do you recognize a bullsh*t strategy?

One, they are expressed as goals, without saying anything about how to reach those goals.

Two, they are generic and shared by pretty much all the other brands and companies in your category.

Three, they are fluffy and written in such a loose and broad way that there are no obvious actions falling out of it. What does "leverage synergies" mean? What do you do with that?

A strategy is the unique value a business provides to the market.

A unique value is the benefit your customers get from your product, which they can't get anywhere else, and which a hell of a lot of people want or need.

The intellectual content of a strategy - the thinking behind it - is only half the battle. The other half is converting that thinking into a strategy that is actually usable.

So what can you do?

You can put your strategy through the subjectivity test where you remove all subjective language, anything like 'good', 'great', 'world-class', 'best' and 'smart', and see if there are any substance left.

You could also play the opposite game where you ask yourself if the opposite of your strategy also make logical sense. If the answer is yes, then you probably have a good strategy on your hands because it represents a true strategic choice.

PowerPoint or Word?

Most strategies float around in "The Deck". A nice long PowerPoint presentation with a few pillars, onions, missions, visions, and the like. A PowerPoint lets you get away with all the things that wouldn't fly in a conversation or email.

Instead, just write it the way you'd tell it. 

A single page of A4 with a few paragraphs of argument and explanation, culminating in the punchline ("therefore we are going to do X"). Your job is simply to explain it so that anyone who reads it, gets it.

There should be no difference between your written explanation and your spoken one.

Even a super-crisp strategy is still, ultimately, going to be fairly abstract, so it's important you really land the idea (and get the ball rolling) by listing some key actions arising from it.
  • What must you do to deliver on this?
  • What needs to change?
  • What do you need to stop doing?
  • What needs to be added?

If a strategy doesn't prompt ideas automatically then it has a problem - probably one of being too abstract, and not practically grounded enough.

"No Bullsh*t strategy" by Alex M H Smith

Strategy, strategy and strategy

... or shall we call it an action agenda? 

I loved the conversation between Professor Richard Rumelt and Lenny Rachitsky at Lenny's Newsletter.

Goals, ambitions, visions, missions, values, wished-for end states - none of these things are a strategy.

And it's not true that these things have to be in place before you can have a strategy. Strategies are fundamentally about what you’ll do in response to a challenge. Strategy is problem solving, and you cannot solve a problem you don't understand. 

As understanding deepens, the strategist seeks the crux - the one challenge that both is critical and appears to be solvable.

What makes up a good strategy?

A diagnosis of the situation. Figure out what's going on here and understand the challenge you face. The challenge can be to deal with change and competition, it can be triggered by a large opportunity or it can be internal like outdated routines, bureaucracy, or lack of collaboration.

A guiding policy, i.e. what will you do and what will you not do with the challenge. It is "guiding" because it channels actions in certain directions without defining exactly what shall be done.

A set of coherent actions that will carry out the guiding policy. This part is so easy to leave out because people like to think of strategy as a high level conceptual thing. Strategy is about action. There must be enough clarity about action to bring concepts down to earth.

When deciding what you will do with the challenge, find your source of advantage. Do you know something that others don't? Do you have a skill that others don't have? Do you have a reputation, brand or existing market system that others cannot replicate? Do you have scale, technology, experience or other resources that others don't have?

A bad strategy is fluff and fails to face the challenge, it lacks the diagnosis. If you don't frame the challenge it is difficult to assess the quality of the strategy.

Another mistake is to treat goals as a strategy. Many bad strategies are just statements of desire rather than plans for overcoming obstacles. Good strategic objectives are the outcome of a strategy, not its input.

Bad strategy is the active avoidance of the hard work of crafting a good strategy. One common reason for choosing avoidance is the pain or difficulty of choice.

Good strategy requires leaders who are willing to and able to say no to a wide variety of actions and interests.

Strategy is not mysterious. It is about solving the most important problem you are facing. You need to be focused on something doable and be consistent about it.

Wild west to Agile

History's role is not to help us predict the future, but to prepare us for it. 

Jim Highsmith's career over the last six decades is a good start.

In the Wild West Era (1966-1979), software engineering was in its infancy and the knowledge of how to "do" software development negligible. This era was wild.

The Structured Methods and Monumental Methodologies (1980-1989) era was an attempt to go from the undisciplined wild west to a more disciplined and formal approach, trying to be recognized as an engineering discipline. 

IT projects were generally viewed as out of control, and business managers assumed building software was the same as building a warehouse. Focus on tasks rather than people and team dynamics.

A formation and expanded use of waterfall, control-oriented, and process-heavy methodologies emerged assuming that documentation was sufficient to communicate between groups with no need for further explanation. Variation from the plan was seen as poor execution.

Despite of this, the approaches managed to deliver value. The success and failures of one era form the base for the next.

"IT projects take too long, costs too much, and don't meet our needs". Welcome to The Roots of Agile (1990 - 2000). In response to executives cries for help, software developers began experimenting with iterative Rapid Application Development (RAD and RADical) methodologies, especially for Internet applications.

Focus on value, quality, speed, leadership and collaboration. Waterfall couldn't handle the level of uncertainty with new technology and changing requirements.

The Agile era. On February 11-13, 2001, 17 people met to find common ground, the Agile Manifesto.

The Agile movement is not anti-methodology. It's about restoring a balance. They embrace documentation, but not hundreds of pages never being maintained and rarely used. 

They plan, but recognize the limits of planning in a turbulent environment. Keep well-working teams together rather than continuously reorganizing them.

In the beginning, individual teams received dispensation to try this "agile stuff", and occasionally several successful agile projects were completed, but they where often downplayed: 
  • "It was just a small project", 
  • "It was a new project", 
  • "They didn't have to follow our standards".

Management wanted agility, but with traditional performance measures. To change behavior and culture, you must change measures of success.

In the current Digital Transformation period (2011 - present), the problem isn't scaling Agile, but enterprise-wide scaling of agility and innovation. 

We need to move from predicting and planning for the future, to building a platform that enables us to adapt to whatever happens.

Preparing for the future challenges us to scale an agility mindset, not simply agile methods and methodologies.



The product operating model

Many have witnessed failed transformations, but few have witnessed true successes. 

Moving to the product operating model is a transformation. At the end, it's about consistently creating technology-powered solutions that your customers love, yet work for your business. It's about delivering real results. But what do you change exactly?

You change how you build. Products are managed as an ongoing effort - improving every week until it's decided to sunset it. You do frequent, small releases so you know that it's working and how it's being used.

You change how you solve problems. Empowered product teams are given problems to solve and outcomes to achieve instead of a list of prioritized features, projects and perceived solutions decided by various stakeholders.

You change how you decide which problems to solve. A strong product company has a compelling product vision and insight-based product strategy identifying the most critical problems that need to be solved to deliver on the business objectives. Your strategy cannot be to serve as many business stakeholders as possible.

Pushing the decisions and responsibilities for finding the best solution to the problem down to the relevant product team, and then holding that team accountable for the results also drives the need for new product core competencies (that normally takes years to learn). 

Unless you are willing to establish these new competencies, your transformation hopes will likely end here.

For the product team together with the product manager to discover and deliver effective solutions, it is absolutely critical that they have direct access to:

  1. Users and customers,
  2. Product data, 
  3. Business stakeholders and
  4. Engineers (the tech lead as a minimum).

Fight any attempt to place a well-meaning person or cumbersome process between the product manager and these constituencies.

An honest and accurate assessment of the organization’s current situation is essential to any plan to successfully transform. Be realistic, talk to all levels and look for evidence. 

Start with pilot teams volunteering to be on the leading edge of these changes. Develop the skills of the product teams (bottom up) and the skills of the product leaders (top down). Ensure your CEO supports and is a champion of the change.

Transformation is a long game, and for that reasons it helps to have some quick wins. It could simply be a team that has never visited users starts doing do and shares it experiences and insights. 

Constantly beat the drum, evangelize and show everyone the progress being made.

"Transformed - Moving to the product operating model" by Marty Cagan.