Battles to be won, jobs to be done

In Equinor, we have now helped hundreds of people applying jobs-to-be-done to discover what their stakeholders are actually trying to accomplish or achieve when they use or are about to use their products.

It is about understanding the problem that you are trying to help someone solve.

Why? The extent to which their product helps their users and stakeholders accomplish their job to be done determines the value they perceive from their product.

We want to spend our scarce resources on products that the users and our business really want and need.

The four key takeaways?

First, look beyond the straightforward functional tasks

This is not about listing a bunch of functional tasks that your users and stakeholders currently perform. You instead need to understand their why and what they really seek to accomplish and achieve.

We see that the ones that struggle to come up with a meaningful value proposition have identified jobs that correspond more with straightforward tasks their stakeholders currently do.

Second, don't forget unmet or underserved jobs

When we do this with existing products, we tend to focus on the stakeholders and jobs the product currently serve, and we forget to explore unmet or underserved jobs or stakeholder segments.

What are the things they want to get done that your product (or any other product in Equinor) currently don't help them getting done? Are there any underserved stakeholder segments where your product could play a role?

Third, people also have social and emotional jobs

We experience that people are trained in articulating functional jobs, but their eyes light up when we introduce them to emotional and social jobs.

By exploring the emotional and social components we see value propositions that resonates better with their audience.

Fourth, test your assumptions

We stress the fact that the jobs the product teams come up with are educated guesses and assumptions you need to test afterwards. You can't figure out all this in a Teams meeting, a workshop or by using the right AI prompts.

You need to test and validate the jobs and the value proposition with your audience.

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. 

Today we talk about product management, agile, waterfall, projects, iterative and measures of success. I enjoy putting this in a historical context. Because those who fail to learn from history are condemned to repeat it. History can help us prepare for the future. Jim Highsmith's career over the last six decades is a good start.

Wild West (1966-1979)

Software engineering was in its infancy and the knowledge of how to software development negligible. Software project success was measured by completion and cost. Businesses operated on the premise that the world was predictable and if plans failed to materialize, the problem was execution, not planning. Change was the "unusual state".

Structured Methods and Monumental Methodologies (1980 - 1989)

This was an era where management theory was firmly stuck in the command-control model. IT projects were generally viewed as out of control. Managers assumed building software was similar to building a warehouse. They often knew little about the value of IT systems, even though productivity increased, and focused therefore on "out of control" cost and schedule overruns. 

Structured methods should bring discipline and control to software development.

But the attempt to go from the undisciplined Wild West to a more disciplined, formal approach overshot and focused on the wrong things - processes and documents. 

Formality was mistaken for discipline. Formal processes, phase reviews and documentation added a level of bureaucracy that overshadowed the benefits of structured techniques. It worked for tangible products and construction-type projects though.

The belief was that documentation was enough to convey all the information required by individuals in the next phase of work.

A paper by Winston Royce in 1970 is often credited with introducing the Waterfall model of software development (a term he never used in the paper). However, Royce did not advocate for the  model in its strict, linear form. He highlighted its limitations and risks, particularly the challenge of accommodating changes once the project is underway. To address these shortcomings he argued for feedback loops, overlapping development phases, and the need for more flexibility and adaptability.

But the waterfall lifecycle was greatly influenced by the surrounding ethos, manager's thinking and the serial "hardware" mindset of the times. Departments outside of IT also adapted their work to conform to the serial mindset. For example, accounting started to classify operating (OpEx) versus capital (CapEx) costs.

Too much structure reduced problem solving and innovation; too little created chaos and ineffectiveness.

The Roots of Agile (1990 - 2000)

Executives now cried for help. "It takes too long, costs too much, and doesn't meet our needs".

In response, software developers began experimenting with RAD (rapid application development) methodologies. They assembled a small team, delivered working software every week, and conducted "customer focus groups" every Friday to get feedback. This was about value, quality, speed, leadership, and collaboration.

The 1990s were the decade where software outsourcing to solve technical debt and the high-cost mess began to flourish. The assumption was that less expensive programming could be accomplished with minimal communication. But much of the outsourcing was based on the false premises of predictability and prescriptive practices.

Worse, it stripped internal IT teams of the expertise they would need in the coming Internet upheaval.

The methodology of software development continued to be deterministic and formal in the 1990s, but slivers of RAD and iterative development began to creep in, especially for rapidly expanding Internet applications.

The 1990s were the decade of process for IT. We sought not just perfection in the way we built software, but total predictability. It wasn't enough just to do things right, we also had to say in advance exactly what we intended to do, and then do exactly that.

The Agile Era (2001 - 2010)

Demand exploded. Acquiring and retaining technical talent proved difficult. Many companies didn't have the money or the talent pool to respond to the pressures of the 2000s. IT organizations faced pressure from the high costs. Companies had to innovate and expand their technical and product design capabilities.

Technical debt, which had been growing rapidly, was still almost invisible to business executives. IT struggled to convince business leaders to approve the investments required to reduce technical debt, thereby enabling continuous value delivery.

On February 11-13, 2001, 17 software developers met at the Snowbird ski resort in Utah to talk, ski, relax, and try to find common ground leading to the Agile manifesto.

Many software engineers were concerned about the nascent agile movement. They viewed agile development as a retreat to ad hoc practices of the past. But in reality, teams were highly disciplined, but worked somewhat informally. The emphasis shifted from documentation towards collaboration, replacing traditional formality.

From 2001 - 2004, individual teams received dispensation to try this "agile stuff". Teams focused on iterations, stories, daily stand-ups, backlogs and co-locating teams - but the core technical practices were often bypassed.

Agile projects' success was often downplayed by others: "it was just a small project", "it was a new project", "they didn't have to follow our standards". General comment from Agilists was "We don't need any project management". But the management of tasks rather than people was what they were complaining about.

From 2005 to 2010, success versus failure with organizational implementation of agile development rested with courageous executives who understood agility at their core. Courageous executives thrived on adventure, the corporate kind, and had the ability to sort through a myriad of opportunities, engage others with their enthusiasm, and demonstrate results through action.

Another success factor was that Agilists had enough background in change models to muddle through team-level implementations. At an enterprise level, it made a difference when they received help from organizational change experts.

Do we implement from top to bottom, or from bottom to top? Do we start with a few teams and user their experience to seed others, or do we "sheep dip" everyone? What was the strategy for moving agility up (the organizational hierarchy) and sideways? How do we instill both being agile and doing agile? Whose change model and approach do we use? Agilists were simply not experts in change management.

Other success factors were demonstrated business benefits, practices that appealed to engineers and a manifesto that stated a clear purpose and principles for the movement.

Digital Transformation (2011 - present)

The problem now wasn't scaling agile, it was scaling agility and innovation at enterprise levels.

Remember the lessons from agile projects: To change behavior and culture, you must change measures of success. Many managers wanted agility, but with traditional performance measures (planned scope, schedule and costs).

Over the last six decades, measures of software development success have evolved from completion to customer value. Nothing drives change like the way organizations measure success, but few things are harder to change than those measures.

The Digital Transformation period explored what becoming a digital enterprise meant. Enterprise executives developed digital strategies but found their transition from strategy to operating models lacking.

Enterprises today should be seeking to become digital transforming rather than to achieve digital transformation. Transformation indicates completion of a stage, whereas transforming suggests a constant state of becoming.

More than six decades of change have required organizations to constantly adapt by addressing the following areas:

  • Measures of success - this can drive or restrict change.
  • Being digital demands a better business and technology partnership.
  • An operating model linking strategy to action.
  • Creating a quickly malleable organizational model.
  • Management suited for the digital era.

Preparing for the future

Over the 60 years, have anyone notice the rate of change in the world, in technology, and in business slow down? Change has spiraled constantly upward, not only linearly, but bordering on exponentially.

One conclusion from history is that agility, not agile, should be the goal. Agility is a mindset; agile is a type of methodology. Failure to make this differentiation has left organizations with prescriptive methodologies, while leaders who embrace agility have the best chance of thriving in the future.

Change takes more than a one-day workshop. No one changes deeply held mental models easily. Even when organizations and managers intend to start the journey with the right mindset, many don't realize the magnitude and complexity of this transformation.

The root cause of success is people and their interactions, and the root cause of failure is also people and their interactions.