Full loop product management

Full loop product management is an approach and a skillset that allows product managers to be involved throughout the entire lifecycle of an opportunity. It starts with understanding potential opportunities, brings them into the organisation to align with strategy, creates a means of leveraging the opportunity, and takes it out into the world and measures it’s impact.

Full loop applies to any size or stage of organisation and for new products or for improving existing features. It’s a way of joining up the parts of the value stream that creates products, of giving the whole process more coherence, and so creating more valuable products that leverage the right opportunities.

Full loop product management

Full loop

There are four parts to the loop.

External discovery

From horizon-scanning across an industry to competitor analysis to interviewing customers, external discovery is all about finding opportunities for the organisation and the products.

Internal discovery

Internal discovery involves bringing an opportunity into the organisation and aligning it with organisational and product strategy. In some organisations this involves writing business cases and managing a roadmap.

Internal delivery

Building the new product or feature, and especially ensuring the rationale for how it will leverage the opportunity, is part of internal delivery. This can involve working in agile ways with developers and testers, writing user stories, and communicating progress. This is often where product managers spend (too much of) their time.

External delivery

Delivering the solutions for customers to use includes go-to-market planning, marketing and promotion, and customer support. Monitoring the effect the solution has in the external world completes the loop and informs the ongoing external discovery to understand whether the product or feature is leveraging the opportunity.

When product managers are involved in all sections throughout the loop they are more able to reduce the disjointed lack of connection between an opportunity, a solution and its impact. The more connected and coherent the product development process is, the more value it will deliver.

Some anti-patterns

Internal delivery only

Many organisations focus their product managers on only internal delivery, in the bottom right quadrant. Whenever a product manager job description talks about tools like Jira and agile but doesn’t mention understanding customer needs or measuring outcomes, that’s a sign of an organisation that constrains it’s product managers to only doing internal delivery work. This is the source of the criticism of product managers being used as project managers. If they are not involved in understanding the problem or opportunity, and not involved to launching and measuring the effectiveness of the solution, then all they can do is manage the small part of the loop that builds the software.

Internal discovery and delivery only

A organisation that expects its product managers to only work across the internal quadrants, usually means a product manager taking ideas about often unvalidated opportunities from internal stakeholders and liaising with developers to build something that the stakeholder specifies and thinks will deliver some unspecified value. In job descriptions this often shows in phrases such as “liaising with stakeholders”, “communication skills” and “writing requirements”.

External delivery only

It’s rare for a product manager to be only focused on the external delivery of a product, things like go-to-market plans, marketing, customer support and success, but it’s worth being aware of as there’s an emerging trend of product management shifting more towards marketing in some tech firms.

Using full loop product management

So, how do product managers constrained within one part of the loop start to get involved in the other parts? Those other parts of the loop happen within an organisation. They may not happen in a coherent and robust way, but they do happen. Find out where and how, speak to those people and ask to learn about what they do. Get involved. Find ways to make their lives easier. Move upstream and downstream, and connect people and ideas along the way.

Coherence doesn’t happen by accident, and is so easily lost in the handover between teams and across different parts of an organisation. Full loop product management fixes that.

Weeknotes #281

Photo:

Did:

👋The end

Last week at the Prince’s Trust. It’s been a turbulent two years for the Trust (not because I was there, there were other factors) but I feel like I always managed to maintain my even keel to understand what problems I’m trying to solve, treat all my colleagues with kindness, and help the org learn a little about being a more digital organisation. I received this Kudoboard from some of the people I worked with. It seems like a better testimonial to my impact than delivering any product.

👀25,000

My website has received 25,000 views and it only took six years.

The three most successful posts account for 21.23% of views:

The top ten posts received 9417 views, which is 43.27% of total, and is mostly from organic search traffic as they seem to be about things no one else has written much about.

The top twenty percent of posts account for 85.63% percent of the views.

317 posts have received 10 or fewer views, which accounts for 9.16% of total views.

🕸rogerswannell.eth

Started setting up the ENS for rogerswannell.eth. Web3 stuff continues to divide people on Twitter (and the rest of the internet). There are so many perspectives. It’s really interesting to get a glimpse of how people think about things like this and the (usually unbalance) arguments they come up with to defend their position. I’m no expert but it seems that, for example, arguing that the cost of compute power makes web3 a failure when web3 isn’t trying to solve the problem of cost-efficient computing is like criticising candy floss for not being a good building material. Is web3 a scam? Well, yes, just like every other market that uses imaginary value exchange. And the Pareto principle always applies; a few get really rich and most get poorer.

🌍Top 0.000000052% of the population

The Irregular Ideas newsletter had a hundred per cent open rate this week. That’s not that impressive given that I only have four subscribers but I’m glad that after eight issues they are still opening it. Evan Armstrong wrote in the Napkin Math Newsletter, “Nothing about email or subscriptions fixes the problem of building a media company. Namely, it is just really, really hard to make interesting content every week and to get people to pay attention to it… Newsletters are here to stay and the trend won’t go away, but Newsletters will slow down as independent, focused businesses. Instead, expect newsletters to pivot into mutli-media companies because other formats are quicker and easier to create.” It’s a fair point. Newsletters are just a channel for expressing ideas, so firstly you’ve got to have ideas people want to know about and secondly you’ve got to provide them in the way people want to consume them. I’m not convinced that any idea/expression-of-an-idea can work on any channel.

🌈Red and yellow and pink and green

I completed module two of the BSL course covering numbers, colours and organisations. I know I’m still at the basics but I’ve surprised myself with how well I’ve been able to remember the signs.

🕔Eventually

Futureskills email continue to progress very slowly. I really need to stop coming up with new ideas and get this one to a point where it can launch. I’ll try to make it my main focus over the few weeks remaining of this year.

📖Side-project playbook

I’ve been starting to work on what a playbook for my side-projects might look like. ‘Start with a domain name‘ seems like something that would be part of it. I haven’t always started all of my projects with a domain name but having thought about it, it seems like a good idea. Having a domain name for a project starts to give it an identity and some brand, which is useful however the project pans out. My current projects:

Read:

🤼Digital civil society

The beautifully written ‘Digital Civil Society: The Annual Industry Forecast‘ by Lucy Bernholz has some really interesting and forward-looking thoughts about the dramatic changes coming to a society near you very soon. The phrase, “Disruption is something well-resourced, valorized individuals and companies do unto others; discontinuity is done unto all of us.” caught my eye and summed up the wrestling that is going on between governments, corporations, civil society bodies and individuals.

🤷‍♂️Answering the ‘why’ and the ‘how’

Philippa Peasland wrote this brilliant reflection on driving digital transformation by adopting decision stacks. It’s really interesting to get some hint of how the interplay between a simple tool and the complicated organisational dynamics takes place. As Philippa says, it’s the conversations that count. Changes happens in the minds of the people before it happens in the behaviours of the organisation.

📉Effort and reward

Mark Manson talks about how we should “teach [our mind] to stop chasing its own tail. To stop chasing meaning and freedom and happiness because those only serve to move it further away from itself.” The lesson of the piece is thought-provoking enough, but more interesting is the relationship between the three graphs he refers to in describing the three types of tasks we all perform. He says when an “action is mindless and simple effort and reward have a linear relationship. Effort and reward have a diminishing returns relationship when the action is complex. But when the action becomes purely psychological—an experience that exists solely within our own consciousness—the relationship between effort and reward becomes inverted.” These bear more thinking about from a productivity and planning point of view.

Thought about:

🤝Project and Product

Product thinking is different to project thinking. No doubt about it. But that doesn’t mean they need to viewed antagonistically, that for one to be right the other must be wrong. Good things happen when project and product thinking are merged in ways that work for the environment and circumstances. Don’t identify by job titles, the team is the unit of delivery.

⏳Timing

The more I think about it the more I’m convinced that timing is the single most important factor for the success of anything. Whether it’s a startup launching a product, a business delivering a project, or an individual trying to achieve anything at all, if you can’t answer the question, “why now?” then you’re just guessing. Validation efforts, then, shouldn’t just be about the idea, they should be about answering that “why now” question. Being too late, too early or on time is far far harder to understand, which is probably why we don’t really try to.

👩‍🏭Work mashup

Good work provides choice. Office/hybrid/remote or synchronous/asynchronous, work should work for everyone. We should be figuring out how to create bridges between these things rather than arguing about which one will win. One small attempt I’m interested in using more is meeting notes. I think, done well, meeting notes can bridge between synchronous meetings and asynchronous work after the meeting. I just need to figure out what good meetings look like.

💻Working for the algorithm

This tweet by Aprilynne Alter got me thinking about the myth of how different solopreneur/indie hacker/creator work is to being employed by an organisation. I think they are more similar than they are different. The suggestion that this way of working builds a future of passive income doesn’t stack up. If you don’t keep producing then income will reduce over time. And scaling of income and progression prospects work the same whether you’re working for an organisation or the algorithm; the few get to the top and make lots of money whilst the majority are poorly paid. Some of the comments in Aprilynne’s tweet talk about producing more content based on what previously performed well, which is the same as being employed and . The same mechanisms apply to work whether you’re working for an organisation or working for the algorithm, don’t convince yourself otherwise.

Weeknotes #278

Photo of the week:

Season’s greetings, by Banksy, ironically displayed within a shop.

On this week’s Done list:

Connecting concepts in systems

I’ve been working a lot this week on how different systems ‘conceptualise’ things and how those concepts move between systems with very different data structures as the data moves between them. The same ‘concept’ is defined in different ways and needs translation and common language between the systems. What constitutes the identity of a user in one system isn’t the same as in another, but it’s easy to miss the impact of the differences if you don’t dig into them.

Irregular Ideas

Sent out the thirteenth, fourteenth and fifteenth irregular ideas. I feel like my writing is getting a bit better with the constraints of talking about a specific idea, only having a few paragraphs to do so, and putting it in an email so I can’t change it later. It’s different to writing a blog post where I’m more likely to throw in lots of loosely connected things.

Future Skills

I worked on the first email for the Future Skills guided learning to try get the template right which will hopefully make writing the other nineteen emails quicker. I need to give it lots more time and get the emails written and set up so I can start marketing it. Of all my side-projects it feels like the one that has the most potential for actually meeting a need rather than just being of interest to me. I think it might still not be practical enough but until I get some people using it and get some feedback it’s all guesswork.

Systems-shifting product management

I set up a project page on my website and started to try to define systems-shifting product management, including the idea that product managers develop by learning how to increase their leverage rather than gaining influence and authority within the organisational hierarchy.

Stuff I read and listened to this week:

Public service product management

I listened to Tom Loosemore on ‘the product experience’ podcast talking about product management in the UK government. He talks about how part of product management is creating that space in organisations to do product management, that understanding user needs is do much harder then we think, especially in environments with messy and uncertain human behaviours and that joining up teams, channels, and solutions is essential for achieving the real outcomes for people.

Using maps

Simon Wilson, also on ‘the product experience’, talked about using mapping to know where we are and where we’re going. Mapping, and working in visual ways, are useful for bringing the users of a service forward into people’s thoughts. Maps help us understand the shape and scope of a problem, who it affects, how it affects the organisation. They show us a narrative and help us understand movement.

Decentralise decision-making

I read Jason Yip’s post about using doctrine to allow safe decentralised decision-making by establishing consistent decision logic. He writes/quotes, “Strategy doesn’t give employees enough guidance to know how to take action, and plans are too rigid to adapt to changing circumstances. In rapidly changing environments, you need doctrine to get closer to the ground. Doctrine creates the common framework of understanding inside of which individuals can make rapid decisions that are right for their circumstances… If strategy defines objectives, and plans prescribe behavior, then doctrine guides decisions.” Jason proposes an Agile doctrine:

  1. Reduce the distance between problems and problem-solvers
  2. Validate every step
  3. Take smaller steps
  4. Clean up as you go

There’s nothing much to disagree with, either the idea of a doctrine or the things Jason includes within the Agile doctrine. And I completely agree with the problem he’s trying to solve, how to bridge the gap between strategy and plans in a way that fits with modern good practice for cross-functional autonomous teams. The challenge, as always with these things, is the broad context they have to be conceived for and the narrowing of the context for them to be applied.

Three tech trends charities should know about

It’s great to see the emerging tech trends of metaverse and NFTs being talked about more within the charity sector. It’s always hard to start because the typical response is often cynicism and disdain (even from people who you’d expect to want to consider new technologies with an open mind) but given the increasing speed of change it’s even more important that charities do start to understand new tech. Broadly, I think there are three areas of impact new tech might have on a charity that bare some thinking about. The first is how it might affect the people that a charity is trying to help, e.g., gambling charities should definitely be keeping up with how metaverse games will affect gambling behaviour. The second is how new tech might affect the charities existing ways of doing things, e.g. social media fundraising, which to many fundraisers probably looks like just another channel. And then thirdly, how the new tech might disrupt charity business models, e.g., Decentralised Autonomous Organisations forming the basis for a new way of tackling a cause.

Thought about this week:

The discipline

Following on from product managers product managing product management, I’ve been thinking about the discipline of product management. I guess I use the term ‘discipline’ to mean a structure practice, almost like a martial art where the same moves are learned through repetition which means the practitioner can then put those moves together into sequences that work with each other and not against. This discipline and practice, if adopted, accepted, appreciated by an organisation, brings a balance of order and flexibility to how an organisation makes decisions about the products it develops and runs. It brings clarity to what’s important, and uses that to set focus. Perhaps one of the benefits of this discipline is making it easier to see when something breaks from the discipline and disrupts that clarity and focus.

Which way to work

My current side-projects include Systems-shifting Product Management, Irregular Ideas, Future Skills, and future.charity. Along with also doing online courses and writing blog posts (such as weeknotes), I feel like I’m not really making progress quickly enough on any of them so I’ve been trying to figure out the best way to work. I’ve scheduled time for each project one day a week to try to make progress on all of them at the same time, but I still continue to question whether it’s better to choose one project and set myself a bigger chunk of work to do over a few weeks before moving onto another. Before this scheduled approach I just picked whichever project I felt like working on that day, which gave me more flexibility to do easy work when my mind needed a rest and more complicated work when I was looking for more challenge, but lacked structure to get me to actually work on things I might not really want to.

My growth area for this week

Letting go

Definitely letting go. Still a challenge, probably always a challenge, but an important lesson to learn.

What good product management in charities looks like

I don’t have the answer. But I’m pretty sure that it is rooted in compassion, kindness, integrity, justice and inclusiveness before it even thinks about product practices or applying them in the context of a charity. That’s the hard stuff to get right. Without that it’s easy to go astray and with that the rest of it looks easy.

A Leverage Points Framework for Systems-shifting product management

Systems-shifting product management builds on the work of systems-shifting design which moves away from user centred practices in order to affect change by effecting systems.

How might product management use a Leverage Points Framework

Based on the Center for Humane Technology’s Leverage Points Framework, which is based on Donella Meadows ‘12 Leverage Points to Intervene in a System‘, here is version 0.1 of the Systems-shifting product management Leverage Points Framework.

A Leverage Points Framework for Systems-shifting product management

The core concept of a leverage framework is to illustrate that there are multiple points at which leverage can be applied to achieve an outcome, that depending on where on the lever the leverage point is the more or less effect it will have on the outcome, and that multiple leverage points can be used together to increase achieving the outcome.

1 – User action. Leverage applied here is about providing the means for a user to perform an action.

2 – Feature. Leverage at this point involves change to existing or new features in an attempt to achieve the outcome.

3 – Product. Product-wide changes or new products utilise leverage at this level.

4 – Business model. Changing business models applies leverage at this point on the lever.

5 – Organisation. Changes within an organisation can have high leverage on outcomes.

6 – Culture. Changing the culture has the highest leverage in achieving an outcome.

What might that look like in practice?

Example: Let’s saying we’re looking for ways to reduce misinformation on Twitter.

The lowest leverage change that could be made would be to introduce something that relies on a user action for achieving the outcome. That could be something like displaying a message asking the user if they want to read an article before they retweet it. Low leverage changes are quick to introduce but find it extremely difficult to achieve the outcome alone.

The second point on the framework is to introduce a feature that aims to achieve the outcome. This is higher leverage than point one as it is always available for all users and doesn’t rely on a user action. For our example this could be changing the algorithm to reduce the reach of retweets with links so that fewer people then click on and read the article.

Point three is at the product level. This means either wholesale changes to an existing product or a new product. For the purposes of this example lets imagine a very different Twitter where the algorithm tries to keep users in bubbles, reduces the number tweets in users’ timeline that are counter to views they’ve shared, or anonymises content to expose users to different perspectives but prevents the originator from being attacked for expressing them.

Point four is about how changing the business model can achieve the outcome. Twitter relies on driving user engagement in order to create ad spend in order to generate revenue. If social media sites over a certain size were considered a public good and part of the essential infrastructure of countries there could be an argument for governments contributing to revenue in return for Twitter reducing the need for increasing user engagement with certain types of content.

Five is leverage at the organisational level and could include changes to the company structure, incentives that drive behaviours, success measures, the diversity of people working there, how inclusive open to different points-of-view the corporate culture is.

The sixth and highest level point of leverage is to change the culture. This means changing what society considers acceptable behaviour, legislating against certain organisations and public figures to prevent misinformation, or putting memes to work against misinformation.

Or a simpler example: increase revenue.

  1. Send a user more emails, so they click more links, and buy more stuff.
  2. Introduce a feature that users pay more for.
  3. Introduce a product that solves a different problem, and which users pay for.
  4. Change the business model. Move upstream in the value chain, e.g. from buying something from another business to producing that thing that other businesses buy from you.
  5. Restructure the organisation to downsize departments with higher costs.
  6. Change the culture, create a trend so that more people desire what you produce.

Why do product managers struggle to achieve outcomes?

Because they almost always work at the lower levels of the lever. Why do product managers work at the lower levels? Because organisations often really don’t want to change in order to achieve outcomes, especially if they feel they are succeeding with their current features, products, business models, organisational structures and cultural view of the world.

Not only is is hard to do, it’s also difficult to be sure you’ll achieve the desired outcome. Any action in a complex system will have unintended consequences, but higher leverage changes are more likely to have vastly disconnected consequences which are impossible to tie back to the change.

Against frameworks: a whole person approach to product management

Frameworks are such a part of product management that a google search returns 87,400,000 results. There’s even a website dedicated to product management frameworks.

Frameworks are essentially a shortcut to thinking. Want to prioritise features? There’s a framework for that. Want to create a roadmap? There’s a framework for that. Need to rank customer problems? There’s a framework for that.

Maybe product management depends too much on too many frameworks and abstract concepts and not enough on developing the thinking skills to understand what problem the product manager is trying to solve and create a corresponding and relevant solution.

A whole-person approach to product management would place greater emphasis on developing the more fundamental skills of cognitive, emotional, and social skills. It would encompass aspects of the identity of the product manager and how that affects their ability to do their job well. The whole person approach to learning has been shown to be effective in family businesses, MBA programs, and in care settings, and could be applied to product management learning and development.

Product managers product managing product management

There are a only a very few roles within an organisation where the skills of that role enable the holder to apply them to the role. People who work in HR or Finance can’t apply the thinking of their specialisms to how their role works in an organisation. Of course, it’s beneficial for all roles or teams to appreciate what problem they solve for their organisation, but very few of them get to shape how they solve that problem. The role they play is well shaped and clearly defined. Maybe we could expect Sales people to sell their role within an organisation, and maybe we could expect Designers to design how their role fits in the organisation. And maybe Product manager can product manage their role in an organisation.

They can attempt to understand the problems the organisation is trying to solve by having product managers and shape how their role solves that problem. Is essence, the role becomes a product that enables a value exchange between the product manager or product team and the organisation.

I wonder if product teams that take a product management approach to how they operate within the organisation might be more successful. Rather than adopting a fixed approach they can set hypotheses about what might work better and then run experiments to prove or disprove it. They can use prototype processes to test and validate ideas about how to work. And once they have a process that looks promising, iterate on it as the working environment changes.

Product managers should product manage product management.

Product management in charities and public health: how different is it?

The role of the product manager in high-entropy environments

Trilly Chatterjee’s post about the framing of the product manager’s role, particularly in the public health space, prompted me to try to pull together some of my thoughts about the role product managers play in charities. Trilly starts with the challenge of explaining what it is that product managers do, and how this seems to apply in all sectors and industries. He also highlights how product managers have “very different routines depending on the particular context of their product or service”.

Then specifically speaking about the public health environment, Trilly goes on to explain how there are many perspectives, tensions, trade-offs, processes, people, teams, departments, etc., often pulling in different directions, that all together create an environment of high entropy. In high-entropy environments, where things tend to fall out of alignment quickly and easily, a product manager’s role is to maintain alignment. They achieve this through conversations. Trilly’s point; conversations are the first best tool for reducing the entropy. Or to put it another way, keeping people talking to each other reinforces alignment between the problem and the solution.

I wonder if the product manager takes on this role purely because there aren’t other mechanisms for maintaining alignment and so preventing entropy in the system. If this is the case, then the working environment/system is a causal contributor to why the role of product management is so hard to define. In a very different environment, a small tech start-up for example, a product manager might not need to focus on conversations to as a means to maintain alignment. Different environment (low-entropy), different need (other mechanisms in place), different focus for the product manager.

The goal of the product manager in all environments

So… is product management in charities different to in the public health sector?

Public health and charity, at first glance, look like they could be quite similar. Both are about helping people and both deal with complex multi-faceted problems. But even the slightest scratch beneath the surface shows more fundamental differences than similarities.

Starting with the funding model, public health is centrally funded whilst charities usually receive their income from a diverse and often uncertain range of sources. This matters because how organisations are funded underpins how they organise and manage resources. Although no public health or third sector organisation is ever funded sufficiently to meet the demands placed on it, the funding ecosystem in which an organisation sits makes a huge difference to how the value-chain operates.

Secondly, branding and public perception. The National Health Service, under one banner, is made up of thousands of separate organisations. The charity sector consists of hundreds of thousands of organisations, all under their own brand. For all the benefits it brings, the NHS brand creates an expectation of joined-up-ness that just doesn’t exist in the charity sector. And perhaps it is this expectation of joined-up-ness in a disparate eco-system of organisations, processes and technologies that creates the environment where for a product manager to facilitate the value exchange between organisation and end user they first have to facilitate the conversations that create some kind of connectedness that allows the value chain to product something of use to the user.

From these examples it’s easy to see how the environment that the product manger’s operate in is very different. But, what the product manager is trying to achieve is very much the same.

At it’s most fundamental level product management is about facilitating the value exchange between the organisation and the customer/user/beneficiary. In some organisations the product manager focuses their effort on the sharp end of the value exchange, on the point of interface, the technology the customer interacts with to make the value exchange happen. In other organisations product managers have influence over the entire value chain, the strategy for taking organisational resources and packaging them in a way that is of value to the user. Neither of these positions, or anywhere in between, is more of less important a role, or of greater or lesser value to the organisation. How a product manager fits in the organisation is most often a factor of how the organisation arranges itself, as we’ve seen in the differences in the environments between public health and charities, than it is in the definition of the role itself.

The opportunity for product management in charities

But what about product management in charities? Product management in the charity sector is still fairly new and immature. It feels as equally misunderstood as product management is the public health sector, partly because of the lack, or misunderstanding, of definition, and partly I think, just because of how new it is.

A point I’m always keen to make when talking about product management and charities is that the product management function of an organisation doesn’t necessarily require someone with the job title ‘product manager’. Product management should be viewed more as a mindset and a skill set than it should as a job. Lots of people working in charities, with all kinds of job titles do product management work, it just isn’t framed as such. Perhaps this point of view makes defining what product managers do even more cloudy, but if we .

Charities, even the biggest of them, don’t have the high-entropy environments in the same way as the NHS. That doesn’t mean alignment is easy, it just means the differences between those people and things that should be aligned are less.

Traditionally, an organisation’s value-chain applied ‘engineering thinking’. Engineering thinking is based on the assumption that a problem can be understood upfront, a solution defined, developed and then delivered, resulting in no more problem. And if you’re building simple solutions to tame, well-understood problems, that approach fits. But then the world got more connected (blame to internet if you like) and the problems became more complex, and so engineering thinking ceased to be the best way to solve problems. But many charities continue to apply this thinking to the products and services they provide.

Nowadays, more organisations are applying ‘design thinking’ to how they approach solving problems. Design thinking recognises wicked problems and says that the best way to even start to solve highly complex problems is to experiment, use prototypes, get feedback, understand what effect your solution had on the problem, then try again and again, learning more each time. None of this can be done upfront and then delivered, it can only be done in real-time with real people in real life situations. Increasingly we’re seeing charities adopt design thinking approaches to problems.

What does this have to do with product management? These more complex problems require more advanced means of managing in order to reach a solution. This is where the modern product manager steps in. Their role is, as Trilly says, to facilitate alignment, or as I’ve written before, to interface, integrate and iterate. Importantly, managing alignment between the people within an organisation is done in service of managing the alignment between the problem and the solution. That is any product managers ultimate goal; to ensure the solution solves the problem.

Whereas a product manager in the vast public health system might only work across a thin slice of the value chain, product mangers have increasing scope in charities to work across the entire value chain. They can mange the interface between the charity and service users and supporters, usually using technology to provide the value exchange mechanism. They can manage the integration within the organisation, vertically between strategy and the logistics of delivery, and horizontally between different teams. They can manage the iterating of the solution to apply that design thinking approach to solving complex problems.

Charities need good product management because charities face increasingly complex problems.

Weeknotes #274

Photo of the week:

One day something else will be looking at whatever we’ve left behind

This week I did:

Architecting for uncertainty

We’re getting into the hard work now. Well, the developers are, I just try not to cause too much confusion. It’s a bit of challenge for us to figure out how to build a product that will most likely have to be able to do things in the next six to twelve months that we don’t know about yet. It means being slower and more considered now to architect the systems in more complicated ways to give us flexibility later but that’s better than taking the easy route now and having to fix it later.

My idea that product management is about interfacing, integrating and iterating came into play this week, mostly around the integrating part. I’ve been thinking about where in their different systems and processes different channels might touch and begin to test ideas for a multi-channel approach. Those touch points will be where in the journey a user can switch from one channel to another, mostly on the assumption that the current channel isn’t working for them.

Irregular

I started a newsletter about the idea as the fundamental unit of value. I only have three subscribers, and I don’t know how regularly I’ll send it . One of things I often toy with is how to decide where to write things. Should it be a blog post, go in a newsletter, be a Twitter thread, or probably better for everyone, just an idea in my notes. Giving the newsletter something specific to be about should help me decide which writing goes where.

Centering values

I’m still (slowly) working through the Humane Technology course and am on the module about values. It starts by talking about the myth of neutrality in technology, people and metrics and goes on to talk about how we might approach developing a values rather than metrics and market driven approach to product development.

Blog posts

I wrote a few blog posts this week (well, nine). Some express a single idea and some try to bring ideas together. I’m trying to be more relaxed about writing blog posts and not have to feel like every one needs to be research and have references. They should be more a way to express ideas in progress rather than present finished thinking.

And thought about:

Whole person product management

I’ve been thinking a bit about how product management is presented in blogs and books as being about models and frameworks but when you get into it, it’s all about people. User needs should express actual people’s goals, values and aspirations. The pretend objectivity of prioritising by mapping items on two by two grid when really it’s the conversations between people that actually make the decisions. The roadmap that presents a finished vision of the product when really it’s a point-in-time summary of lots of thinking. I wonder if there’s a need to admit that effective product management cannot be done solely by relying on the concepts.

Where in the value chain

I’ve been working on the idea that the reason for the variety of definitions of product managers and types of product management work is that product managers work on different parts of the value chain. Some, maybe in an early stage start-up, might work cross the entire value chain, whereas in a different type of company a product manager might work more around the interface between company and customer, and in another type of organisation the product manager works only on a specific part of the value chain to do with the technology. This might help to explain the differences but it should also mean that we think of product management as equally important wherever in the value chain it happens.

Starlings have us beat

I was thinking a bit more about stigmergy again and whether it could be used within an organisation instead of strategy. Since writing that post I’ve started to wonder if actually stigmergy does already occur in organisations through informal information networks whilst strategy continues to be applied through formal hierarchies of authority. Maybe it’s obvious that both would have a place in a modern complex organisation. Maybe it’s naive and simplistic to think that an organisation could run effectively in the way a flock of starlings or an ant’s nest does. I’ve often thought that organisations have ‘shadow strategies’ that drive the things people actually do. Maybe that’s stigmergies at work.

This week I read:

System-shifting design

I read the Design Council report exploring some of the known issues with user-centred and solution-focused design and the emerging practice of social design that is “challenging the deep structure of current systems and working at different levels of a system to drive change“. I first heard about Social Design in the service design course I did and am interested in how it can be applied to product management. I think it’s long overdue in recognising the downsides of designing for an idealised user and can hopefully help us consider more about where are the right places to interact with systems to affect how they work.

Optimising the live virtual learning experience

This framework for improving VILT (Virtual Instructor Led Training) within organisations has some suggestions on improving learning. It doesn’t have much depth as to the rationale for improving learning in organisations, other than a few mentions of things like employee retention, but it’s another angle on the evolving space of online learning. It started me thinking about whether there’s any correlation between how much an organisation invests in the learning of it’s employees and how successful the organisation is (or to be more specific, how successful it is in responding to change and innovating).

Bootstrapping

I started reading the minimalist entrepreneur by Sahil Lavingia, who built Gumroad. From what I’ve read so far, it’s interesting how it reflects many of the trends I see in the creator economy, things build an audience before you build a product.

My growth area this week was:

Keep your head up

Trying to shift focus from the specific details of solution design to how we deal with the uncertain future.

The impossibility of answers

A product manager’s primary purpose is to answer ‘why’. Why that market. Why this customer segment. Why those customer problems. Why this solution. Why build this thing rather than that. Why that feature should work this way. Etc., etc., etc. A thousand whys. And never enough answers.

This is the product manager’s paradox; that most of these questions can never be answered with any certainty and for every answer there are even more questions to ask. It’s not enough to simply ask ‘why’, a product manager should be focused on answering why, even knowing the impossibility of answers.