Can product management tackle wicked problems?

The search for scientific bases for confronting problems of social policy is bound to fail, because of the nature of these problems. They are “wicked” problems, whereas science has developed to deal with “tame” problems.

Horst W. J. Rittel and Melvin M. Webber

Product management, at least as typically practiced, uses the scientific method as the basis for answering questions and establishing new knowledge.

Rittel and Webber claimed that science cannot deal with wicked problems.

So, can product management tackle wicked problems?

Not the tactical product management as we usually think of it, and not even where product management is able to act strategically, but perhaps where product management can effect systems change.

Product management that seeks certainty will never tackle wicked problems. But product management that embraces uncertainty, and works with complexity, maybe that can.

What product/market fit might look like for charities

The concept of product/market fit was created by Andy Rachleff, from Benchmark Capital, and Don Valentine, from Sequoia Capital. And then popularized by venture capitalist Marc Andreessen. This means the concept has a very specific context and history, which makes it slightly problematic for other contexts.

With that said, let’s see how the concept might be applied to a charity context.

Product/market fit means being in a good market with a product that can satisfy that market

– Marc Andreessen

In a charity setting, the dynamics of product/market fit are very different.

The market isn’t made up of customers who are or aren’t willing to pay for the product, which means that willingness can’t be used as a signal of fit. For charities, the market is three-sided with the user, the funder and the charity. A good market would be one where the people are facing a significant problem that funders want to support solutions to.

Charities tackle wicked problems. Even the most successful products are only ever a small part of solving wicked problems, which means the product can’t provide clear signals of how well it is satisfying a market need.

Product/market fit is an important concept for charity product management, but it needs a lot more work to understand it properly.

Standards to assess products

Good products are:

  • Accessible
  • Cost-efficient
  • Data usage
  • Ethical
  • Maintainable
  • Managable
  • Performant
  • Private
  • Safe
  • Secure
  • Sustainable
  • Usable

Naturally occurring work in progress limits

If work is waiting 90% of the time, then only work is ever in progress for 10% of time. Does this impediment to flow create naturally occurring work-in-progress limits?

Work can be waiting for all kinds of reasons. It can be waiting for approval, waiting for someone to become free to pick it up, moving between roles.

Reducing the time work is waiting is one way to reduce the time it takes to get value from that work. But sometimes that isn’t possible, so it’s necessary to work without applied work-in-progress limits.

How we define ‘in progress’ matters. Is work in progress if it has started but isn’t finished? Or is work in progress if it has been started, is actively being worked on, but isn’t finished? In which case, work that isn’t being actively worked on is ‘work in waiting’.

One perspective sees time spent ‘in waiting’ as waste. If that work was finished sooner, then more value would be realised from it.

But, having work ‘in waiting’ creates a natural limit to work-in-progress.

Delivery management and product management: perfect partners

If product management is a science, delivery management is an art.

If product management is about analysis and hypothesis, delivery management is about relationships and harmony.

If product management is about the destination, delivery management is about the journey.

Product and delivery are complementaries, opposites but fitting together to make a strong whole.

What valuable, viable, feasible means in charity product management

Product management attempts to reduce the risks associated with building a solution that isn’t valuable, viable or feasible.

Marty Cagan describes these types of risk:

  • value risk – whether customers will buy it or users will choose to use it.
  • business viability risk – whether this solution also works for the various aspects of our business.
  • feasibility risk – whether our engineers can build what we need with the time, skills and technology we have.
  • (Cagan also includes a usability risk – whether users can figure out how to use it, but for simplicity I’m going )

For a charity, these risks show themselves in slightly different ways, but a product still has to be valuable, viable and feasible.

Valuable

The value risk is tackling a problem no one wants solving, or providing solution no one wants to use. To be valuable, the solution has to tackle a non-trivial problem that affects enough people significantly that it’s worth solving.

Viable

The viability risk is tackling a problem that the charity isn’t the right one to be tackling. To be viable, the solution has to fit the organisation strategy, be a legitimate problem for the charity to be tackling, and be fundable.

Feasible

The feasibility risk is of not having the skills, knowledge, technologies, to create the solution. To be feasible, the solution must be within the capabilities of the charity to build and, just as importantly, maintain.

Valuable, viable and feasible

Creating a solution that is valuable, viable and feasible is the challenge of product management in charities, but reducing the risk of not doing so is the value product managers bring to charities.

Charity mission and vision for defining boundaries not goals

I’ve written previously about why I don’t think charities should be working to put themselves out of business.

Maybe we’ve misunderstood mission and vision and that’s where we get the idea from.

If we think of a charity’s mission and vision as a goal to achieve then the logical conclusion might be that once the goal is achieved, there is no longer a need for the charity to continue to exist.

But if we think of mission and vision as setting the boundaries for a charity, defining the area of influence, it’s market space. Now the charity can do any work within in that space. Even if they solve a particular problem, they are free to shift their efforts to a different problem or expand their space and continue to do good in the world.

How new changes get adopted

Rogers’ adoption curve model, a model for understanding how new ideas and practices are adopted, helps us create a realistic approach to bringing about any new change.

How adoption happens

Roger’s adoption curve tells us to expect that for any new change, the number of people adopting that change is different throughout the lifecycle of that change. A few people will adopt change early, more as the change becomes generally accepted and there will be a small number who take longer.

Roger's Adoption Curve
Blue line shows the breakdown of types of adopters by percentage. Orange line shows the total percentage of adoption over time.

We can take this knowledge and use it to help us make change adoption easier. Rather than think that everyone will accept a new change at the same time, we can identify the early adopters and work with them first to get the change embedded. Once these few have accepted the change, it’s easier to move onto larger groups of people.

For example, suppose we want people across an organisation to change how they manage projects:

  • Innovators – Start with a small number of projects managed by people who are confident in using and accepting new ideas and techniques.
  • Early adopters – Projects managed by people who have worked with the innovators and have seen the new approach in action. 
  • Early majority – Projects managed by people who are aware of the projects managed in the new way but haven’t been involved in them, and are proactive in adopting new practices. 
  • Late majority – Projects managed by people who aren’t aware of the new project management approach but are open to adopting practices.
  • Laggards – Projects managed by people who aren’t aware of the new project management approach and are not open to adopting practices. 

How to make adopting change easier

With all groups of people, there are things that can make it easier to accept the change. Successful adoption has five key characteristics:

  • Compatibility – The more it fits with existing behaviour and tools, the more easily people can make it part of their working process. 
  • Trialability – The easier it is to try before having to commit to using it, the more people will start using it. 
  • Relative advantage – If it is better than the alternatives, then people will see the value of using it. 
  • Observability – The more people see others using, the more they will want to use it.  
  • Simplicity – The easier it is to learn, the faster it will be adopted. 

For any kind of change in an organisation, trying to get everyone to adopt something new at the same time is much harder than using proven knowledge and techniques to bring about change over time.

What user stories are really about

User stories do not have to follow the format, “As a [persona], I [want to], [so that].”

User stories do not have to be used to assign work to developers.

User stories do not have to have “story points” or be used to estimate how long work will take.

User stories are so much more…

A user story is a ‘boundary object’, a conceptual object that has can be interpreted differently by different people but which have enough immutable content to maintain the integrity of what it is communicating. They allow “coordination without consensus”, meaning that not everyone has to agree on how to define and interpret the information the boundary objects holds in order to make use of it how they need to.

The concept of boundary objects was introduced by Susan Leigh Star and James R. Griesemer in a 1989. They describe boundary objects as:

Boundary objects are objects which are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.

User stories are a way for people with different domains of knowledge to share a common understanding in a way that makes sense for their specialised knowledge domain and has . A good user story makes sense to a content designer thinking about content and to a developer thinking about code. The story is talking about one thing only, but different people with different perspective can understand the story in a way that makes sense to them.

Writing good user stories isn’t about following a prescribed format, it is about creating boundary objects that work across domains and give people the knowledge they need.

Lightweight digital governance

About lightweight digital governance

What is lightweight digital governance?

Governance is about collective responsibility.

Lightweight governance assumes competency and sets out to create the best conditions for people to get things right.

Lightweight digital governance is about using modern, agile, digital, ways of thinking and doing to create the best conditions for collective responsibility to flourish.

When those conditions exist, things are improved, how they are improved improves, and those improving them see the improvements.

What’s the difference between lightweight and heavyweight governance?

Heavyweight governance focuses on having decision-making controls and checkpoints separated from those doing the work.

Lightweight governance focuses on ensuring people have all the skills and knowledge they need to make the right decisions about their work.

A lightweight digital governance model

Lightweight digital governance

One part of the governance model ensures the thing being governed aligns with strategy, sets the standards, designs the procedures and provides the training.

The other part of the model implements the standards and procedures, does the necessary work, checks it for quality, releases and monitors it to feedback on how well those standards and procedures meet the needs, whether there are gaps in the training, and new things need to be governed.

The model is:

  • Cyclical – the cycle can be monthly, quarterly, annually, etc., depending on the needs of what is being governed, but it relies on a feedback loop for its success. This helps the governance to improve as it improves what is being governed.
  • Separates activities – but doesn’t separate the people or their responsibilities. Those involved in implementing a standard can be involved in using it and providing feedback to improve it.

An example

Governing a charity’s website.

Those involved decide that in order to govern the website effectively that need to take collective responsibility for accessibility, branding, performance, security.

A traditional heavyweight governance model might make different teams responsible for each of those things, but lightweight governance recognises that creates a coordination burden that leads to more trouble than it’s worth, so it’s better that one team with all the skills it needs take on that responsibility.

The team sets the standards for the website, e.g., WCAG 2.1 for accessibility, password length for security, and they write the procedures for checking readability scores or vulnerability testing, and they create training in how to use the procedures to achieve the standards.

They then create content on the website, develop new functionality, etc., applying what they learned in the training, and feeding-back on how that’s working so it can be improved.

The more quickly things move through the cycle, the more quickly they are improved, so critical changes should move quickly and less important change can move slowly.