Category: Weeknotes

This week I did:

Product environment

I presented to the team my thinking about creating an environment for successful product and services. It is a set of guidance and standards for setting up the structural things that are the necessary foundations for any product and service to be successful. I’ve approached it from the perspective of the four big risks and then breaking down the things required to mitigate those risks. The more of these things that are in place, the lower risk of the product and service failing. These things included feasibility mitigations such as security and privacy, and usability mitigations such as accessibility and testing. I’ve been gradually implementing some of the things on the list, starting with feasibility but it feels like it’s time to turn the work into something more formal. The goal is for these things to be foundational so that teams barely have to think about them when they are creating new product and services because they are well-established and proven.

Timeline of digital work

I added the launch of ChatGPT to the timeline of digital work as it seems clear to me that it’s going to have a pretty big impact on digital work.

I read:

7 Indicators for measuring team success

Sense on the beach’s system to maximize team self-awareness and resilience is a really interesting way to think about framing and measuring team performance. It’s hard to balance the external value a team delivers with the internal things they need to be successful.

Inclusive language guide

Oxfam’s inclusive language guide is fantastic. Don’t take any notice of the nonsense in newspapers.

Privacy in the product design lifecycle

The ICO’s guidance on considering privacy in product development says, “If you’re making a product or service that involves processing personal information, it is important to consider data protection law throughout the design and development process.”

And I thought about:

Four types of change

I was thinking about how we might uncover the untended consequences of changes. If we think about understanding change in a two-by-two matrix of how intentional it is and how visible it is, which gives four types of change:

• Intentional and visible – The change people want to happen can be seen to be happening.
• Unintentional and visible – The change people don’t want to happen can be seen to be happening.
• Intentional and invisible – The change people want to happen but they can’t see it happening.
• Unintentional and invisible – The change people don’t want to happen and they can’t see it happening.

I wonder how something like this could be used to uncover how different people think of the same change. So, a group could explore a changing situation and each put things in the different boxes to show whether they think the change is intentional or unintentional and visible or invisible.

How AI changes the Internet

For my generation, the promise of the internet was that we could talk to everyone, buy from anywhere, learn about everything. It was the promise of the ‘large’ Internet.

But large is now the realm of AI. Large language models using massive amounts text and images from across the Internet.

So maybe the promise of the Internet for the next generation is ‘small’. Maybe they’ll leave the large Internet to AI, and make the small Internet for the humans.

This week I did:

Test and learn

I struggled (well, failed actually) to introduce test and learn practices to a project. I think it would be really useful to test the riskiest assumptions we have about the proposition and user experience but sometimes making a thing that appears finished is more important, I get that. I shall consider this attempt a test and learn from it. It made me think about the difference between adopting a well-defined process or framework and introducing a way of thinking about things. Both have their pluses and minuses, but generally I tend towards the way of thinking approach. I wonder if the framework approach is a necessary step to help internalise the thinking before you can work with ways of thinking about things. Expecting someone to question their default way of thinking, challenge it positively, and learn, accept and put into practice a new way, all whilst actually doing the work to progress the project, is a big ask.

What technology does to expertise

I wrote an Irregular Ideas post about how as technology becomes more advanced it creates opposite poles of expertise, with really high skilled experts creating the technology at one end and really low skilled workers at the other, and with the technology in between. It’s the first post I’ve written in a few months, so I’ll probably keep Irregular Ideas ticking along and occasionally write something when it occurs to me.

And I read:

Evolution, Cupcakes, and Skeletons

What’s the best way to deliver and grow systems? Interesting question. Is the answer different to, what’s the best way to deliver and grow products? Thinking about product development as a way to intervene in systems is really interesting to me. And their are plenty of systems to intervene in, those within organisations and those outside (until we breakdown that boundary and see all the systems together).

Roadmap questions

John Cutler produced yet another fantastic resource for uncovering the complexity of the work. 40 (multiple choice) questions you should be able to (eventually) answer about each item on your roadmap provides product managers with things to think about that might help them improve the quality of understanding about the items on their roadmap. I can see it being used in product coaching sessions to prompt thoughts, someone will probably build a UI over it that gives you a score, and product managers will be using it to challenge non-product thinking in their organisations.

Thought about this week:

Product manager skills

Parv tweeted asking about what skills an entry-level product manager should have. A lot of the replies seemed like ‘organisational navigational’ skills rather than specific to product managers (which made me think about what an over-reliance on these kinds of skills says about an organisation’s culture). For me, the most fundamental product skill a product manager needs is scientific thinking, the ability to thinking logically and critically through the steps of the scientific method to reach valid conclusions. It’s a skill that can be applied in all kinds of contexts from a feature solving a particular problem to an entire business model.

Ideas that stick, win

I know we all know this, but the best ideas don’t win. The ideas that win are those that people find easy to understand, talk about, use. This follows on from last week’s thoughts about creating new knowledge and legitimising it into accepted practice. The tension between the dynamic and the static is everywhere. The best, most brilliant, most worthy ideas are useless if no one uses them. That’s why we have marketing.

This week I did:

Website technology strategy

Most of this week has been about applying our technology strategy model to our website to identify where to focus our efforts to get the most value. It worked really well and helped us focus on the things that will improve the infrastructure and get the value from doing so.

In the zone

Add more to productmanagement.zone. I like the filters. If you want a book on strategy or a podcast on discovery, using the two sets of filters you’ll be able to find them. One of the things I need to figure out is, for things like podcasts, should I list each episode or just the podcast. The filtering works better if it’s the individual episodes but it’s a hell of a lot more work.

Starlings and geese

I wanted to write a blog post about starlings and geese as analogies for patterns of team behaviours. Starlings are about to respond to each other and change direct quick, whereas geese are aligned and go a long way together. But I couldn’t make the blog post make sense so I just tweeted it.

Posthuman professionalism

I’m interested in Posthumanism as one of my pillars of thinking for system-shifting product management, so I went to a talk called Posthuman professionalism. It was mostly about the education system, but I found it really interesting from two angles. Firstly, it described posthumanism as post-vitruvian (appreciating difference rather than the ideal human represented by Vitruvian man) and post-anthropocentric (accepting other forms such as digital, plant and animal as equally important rather than thinking these things exist for the benefit of the human species) which is what I like about it for product management that is user-rhizomatic. Secondly, it asked the question of what it means to be a professional, whether it has to be about giving over control to an organisation or whether posthumanism shows a different way of being detached from the organisation. It gave me a lot to think about.

February’s retro

I did my retro of how February went and what I did and didn’t do.

And read:

Knowledge Production and Intellectual Legitimacy

This essay talks about the the dynamic between creating new knowledge and legitimising it as useful product. The same dynamic occurs in many places in many ways, always with the same challenge. It happens across society and institutions, and it happens within fields of knowledge and within organisations. The constantly shifting power of influences in these allow for varying degrees of balance between the new and the existing knowledge, the and the well-established practices. So, the challenge for organisations wanting to be innovative is in how they manage those tensions. Too much new knowledge too quickly doesn’t get legitimatised. Too much legitimacy prevents new knowledge from being accepted.

The Marshall Model of Organisational Evolution

The Marshall Model of Organisational Evolution describes a model for understanding how organisations evolve along an axis of “effectiveness” from ad hoc to chaordic (with effectiveness being defined around minimum waste and maximum productivity).

Toward a Typology of Critical Nonprofit Studies

I’ve thought for quite a while that the charity sector is anti-intellectual and that the ‘doing’ is based on personal experience rather than being rooted in well-established theory. This literature review shows that even scholarly work in the not-for-profit space often fails to engage with critical theories. Such a waste of knowledge that could be put to good use.

And I thought about:

Speed of work

Different types of work progress at different speeds. And the speed is better defined by the characteristics of the work than by external things like deadlines. Work that is well-known, standardised, repeatable and predictable progresses at a different pace to work that is unknown, novel and creative.

Lightweight governance

Thought a bit more about lightweight governance, that is governance that is built around enabling people by giving them the knowledge and decision-making power rather than heavyweight that uses permission and control to centralise decision-making. I’m keen to explore this more and develop it into something useful.

Team identity

Wondering about the purpose of teams, what their role is in an organisation, and whether we have the words to explain it. And how teams see themselves and how other see them, and whether those two are the same. Don’t suppose there are any answers, especially in complex adaptive organisations where those roles shift depending on the people and how they interact.

This week I did:

Product environment

I was on leave this week so had more time to do some more thinking about the things we need in place to be able to tackle the four big product risks of not tackling a problem worth solving (value), creating something people can’t or don’t want to use (usable), not being able to build and maintain it (feasible), and not being able to resource and alignment to organisational strategy (viable).

The layer of things I’m working on is about establishing standards of quality, it doesn’t include processes and practices or team culture stuff we might do to understand and mitigate the risks. That’ll come later. So far I’ve focused on feasibility (because it seemed like the easiest) and usability.

Feasibility includes:

• Data – We need some standards for data quality & integrity.
• Maintenance – We have to ensure we have the knowledge and skills to support the continued operation of the product.
• Manageable – We’ll have to be able to manage the tech, including supplier relationships if we use third-party services.
• Performance – We might use Lighthouse scores for this.
• Privacy – The product has to be able to ensure the privacy of users, not exposing their info to other users, services & organisations, etc.
• Reliability – Setting standards for infrastructure.
• Security – Prevent unauthorised access and attacks. I’m sure there are some standards out there along with best practice guidance on passwords from NCSC.

Usability:

• Accessibility – ISO/IEC 40500 & WCAG (of course) but needs more definition based on the intended audience.
• Mobile-first / progressive enhancement – Not just thinking about how the product looks on a small screen but about how it will work with low phone signal
• Safety – The KCSIE’s 4 C’s of online safety; content, contact, conduct & commerce. Ok, it was designed with kids in mind but it seems like a solid place to start when ensuring online safety.
• Testing – Don’t know if there are any standards for product testing, but there must be some good practices.
• Usability – Maybe ISO 9241-11:2018, Ergonomics of human-system interaction can help.

I haven’t done much around what we need to ensure a product is valuable and viable, but I have some ideas about value involving understanding the problem and measuring the solution, and viable involving alignment with organisational strategy, budgeting and compliance.

Product management zone

I played with Softr and Airtable again to create productmanagement.zone, a directory of product management resources. Got lots to add to the database, and it’ll probably go the way of most of more projects, but I might actually try to get some people to use it and give me some feedback.

User-centred vs user-rhizomed

I wrote a quick blog post about the downsides of placing the user at the centre of how we think and design, and how we could use a rhizome as an organising structure for more varied thinking about how everything connects in the system we’re designing.

How Afrofuturism might provide a framework for thinking about technology charities

I’ve been meaning to write an essay about how afrofuturism might provide a better framing for how charities think about technology than the silicon valley tech-optimism that underpins so much of the tech sector. It turned out shorter than I intended (never a bad thing), but it’s good to get my thoughts written so I can build on them.

I read:

Design the Team You Need to Succeed

This is a really interesting article by Christina Wodtke shared her insights that;

1. There many kinds of teams, and you should decide what kind you need first.
2. Teams have stages, but it’s not linear. It’s iterative. Great teams are willing to storm, norm, perform, then storm again and re-norm in order to constantly grow.
3. Teams need to consciously co-design the core three key elements of a team— goals, roles and norms — to be successful.

Mobile gaming

This mobile gaming report is really useful research for charities developing their gaming fundraising strategy.

Story mapping

“There are few better ways to visualise a product domain and develop a shared understanding of what a product does and how it is used.” I really like story mapping.

Thought about:

Boundaries

I’ve been thinking about the internal/external split in organisations, including Hugh MacLeod’s porous membrane, and what an organisation looks like that uses (as much as is practicable) the same ways of working internally with it’s staff and externally with it’s customers.

Reversing Brook’s law

I have a theory that the reason four day working weeks are so successful is that they reverse Brook’s Law. It isn’t (only) less time at work that creates the benefits, it’s that everyone spending less time reduces the coordination challenge by 20% which is a massive efficiency/effectiveness gain. I wonder whether the studies of orgs doing 4 days a week include measuring work in progress against when they were doing 5 days a week? Do the organisations make more/better prioritisation decisions because of the feeling of having less time? How long does it take for the beneficial effect of four day working weeks to wear off?

This week I did:

Environments

Did quite a lot of work on what the environment should look like for supporting the feasibility of products. There’s lots to do to get to where I want us to be, but I have a pretty good sense of it. Part of this is thinking about how to show the value of the quiet work that goes on in maintaining the technology, but not so sure about this part yet. The next part of the environment to work on is usability. This includes things like accessibility, a mobile-first approach to user journeys, automating some testing.

Product manager leader board

I’m number 3,011 in Product Management on Twitter. Obviously that means I’m more important than number 3,012 (kidding). I haven’t used it yet, but Hive looks like an interesting tool for helping to understand communities on Twitter.

Read:

Governance – the overlooked route to transformation

How we relate, work together, and organise are cornerstones of change making. I’m very interested in governance models as ways of creating change rather than enforcing control and maintaining a status quo.

Documentation in Remote Teams

This is an interesting article about cultivating a culture of documentation in remote teams. Documentation is hard. The usual way to think about managing it is to try to keep it all in one place. But that’s not very internet-y. Better to link between things wherever they are. I think a really useful technique in managing documentation is to create trails from current documents to relevant older documents. The longer and more complex a project, the more links later documents have, which gives anyone looking back through the documents a sense of what came later as it links to early documents, which don’t link forward.

Transformational systemic change

We must increase the scale, speed, impact and meaning of our collective actions toward achieve the Sustainable Development Goals. Mission-oriented innovation attempts to produce transformational systemic change.

And thought about:

Designing for change

When designing and setting up a system, whether a technical system or a social system like a team or organisation, should you design it for how things are now, how they will be in the future, or for the change in between? It’s likely that those three are mutually exclusive and incompatible with each other. Setting up for how things are now might make it harder to change towards the future state. Setting up for how things might be in the future could be wasteful and is definitely risky as we don’t know how things will turn out. Setting up for the change creates disharmony with the current state, and is necessarily temporary, meaning things will have to be set up again as the future state approaches.

Horizon scanning

I did a bit of thinking about how to create a horizon scanner for product managers, how they’d know what to look for in their industry. I also thought about how, to be useful you’d need some sense of trending and analysis of history to see where things might be heading. So, if you were a PM in EdTech right now you’d be all over ChatGPT for what impact it might have in the short term but you’d also be looking over the history of new tech being introduced to the education space and how it hardly ever revolutionises things, but all the organisations use it to reinforce their business models and maintain the status quo. You’d make very different strategic decisions about the impact AI will have on education if you knew how that trend beats the tech emerging tech trend to if you just saw the tech side. You can’t be an effective product manager if you don’t know what’s going in your industry.

This week I did:

Technology strategy planning

If “where are we going to play?” and “how are we going to win?” are the two questions a strategy is expected to answer, then for a charity that operates first and foremost in online spaces and with digital experiences, technology is a big part of the answer. The three things the technology strategy needs to achieve are ensuring the tech meets a need, enhancing capabilities and ensuring business continuity. And this week I’ve been working on how to turn the approach the strategy provides into a plan for doing the work to achieve those goals. The piece that was puzzling me, came to me in my sleep, so now I feel like I’ve got a pretty good handle of it. Now I’ve just got to figure out how to communicate my understanding in ways that make sense to others.

Complexity chat

Had an inspiring chat with Richard Collings about our shared interest in systems design and complexity. The thing that stuck with me most was how connected technical system design is to changes in the behaviours, mindsets and values of the people using the system, and how important it is to consider changes at all levels in order to for the change to be successful. Usually, all that falls below the line of visibility is just called ‘culture change’, so it’s interesting to consider that there might be better tools and a more structured approach.

Four day working week

I’ve been experimenting with a four day working week (actually just using up leave days by taking Fridays off). This is only the second week, so I don’t have much to reflect on, but the hardest thing for me is in letting go of needing to be available so to not to become a blocker. I generally work pretty asynchronously anyway, so not sure why I have that hang-up.

I read:

Writing Culture Challenges

“A write-and-reading-and-feedback-giving culture requires time to think, process, and respond. Writing isn’t the end goal: thinking and improving is the goal.” ‘Nuff Said! (as Nina and Stan said).

From Laudable List to How to Really Win

“The heart of strategy is a matched pair — a place to compete where a company designs an approach that enables it to win. Sadly, most strategic plans do not do so. Rather, they make lists of initiatives which the company will pursue.” Or, strategic as a decision-making tool, not a to do list.

Service design for wicked problems

“Deep Diving into Service Design Problems: Visualizing the Iceberg Model of Design Problems through a Literature Review on the Relation and Role of Service Design with Wicked Problems”. Can product management tackle wicked problems?

And I thought about this week:

Charity product management and maturity models

I wonder whether existing maturity models, like those designed for software development, could be applied to adopting a discipline like product management in a charity. The models aren’t perfect, they’d need some adaption as they often seem to depict the perfect state of each phase without going into the signals we might notice to suggest whether change is happening in the right direction or seeing maturity as a constantly developing process, rather than the ‘freeze/unfreeze’ concept of change. I guess I see it like a roadmap for product thinking in charities and a way for a charity to compare itself against a context-specific measurement framework.

Product management is too inward-looking

So much product talk is around how to improve your roadmap. These are all tactical-level marginal gains for high-performing teams. They aren’t what can have the biggest impact on product management delivering value for the organisation and it’s users. To have more impact, product managers need to spend more time looking at what’s going on outside the organisation. And they need to have the techniques for doing so.

This week I did:

Value, direct and indirect

The majority of our work at the moment is internal-facing. This is an interesting conundrum for me about how we deliver value to our users. There’s an obvious argument to be made for “fixing the plumbing” now in order to provide more value later, and I’m a believer when it comes to creating the right environment for products to be successful. Perhaps a problem occurs when user value and internal work becomes mismatched, and user value becomes tomorrow’s promise. I wonder if there are any signals to show that mismatch, and how you’d get the two aligned.

One of those internal things I’ve been working on is an incident management system. I’m keen to try out the CASTLE framework (Thanks, Jonathan) to help make it as easy to adopt as possible. One of the things that make this system interesting to work on is that it’s really low volume and yet needs to be really really reliable and robust. It’s almost the opposite from a user-facing product where the number of people using it is a fundamental measure of success. But the outcome goal for this system is to drive process and policy improvements that mean the system never has to be used.

Irregularity

I haven’t written an Irregular Ideas newsletter for a few weeks. Life stuff was more important, and the pause has helped me think about why I’ve been doing it and what to do next. I wanted two things from it, one was to be a place to explore ideas around how humanity and technology affect each other. That’s such a broad topic that I would never run out of things to talk about, even though I sometimes struggle to find an idea that interests me enough to spend a day learning and writing about it. And the second thing was to develop a writing style and improve how I express these ideas. I feel like writing the newsletter has helped with both of these, so my question for myself is whether those goals are still motivating enough to carry on with the newsletter.

I read this week:

Delivery Management

I’ve been (slowly) reading Jonny Williams’ Delivery Management. I have this idea that Delivery is about behaviour change within an organisation and Product is about behaviour change outside an organisation. Although they use very different approaches and techniques, the interesting question for me is how connected those two behaviour changes are or can be. Does excellent Delivery Management lead to high-performing teams, which leads to better products, which leads to changing user behaviour? Or is there no causal connection and team performance has very little impact on the success of a product (because other, usually external, factors have over-sized influence). Jonny’s book is helping me figure that out.

Product enablement principles

Another great post by John Cutler. Timely for me as I shape up my thinking about creating the right environment for successful products. John said, “You have to make it easy to do the right thing. At first, people will manually do stuff (you have the early adopters). But later on, you need to nurture the systems and tools that will enable everyone.” We’re at the stage where we need bring more consistency and predictability into how people use systems as part enhancing our capabilities.

Faster, sooner, righter, wronger

I listened to the Troubleshooting Agile podcast about going faster by starting sooner. I like the point they make about learning faster through moving faster. And Kimber Lockhart wrote about not creating a sense of urgency and fostering a sense of purpose. These aren’t competing points of view, just vaguely connected around the theme of speed. We’ve know purpose is important since Dan Pink’s 2009 book Drive introduced the concept of Autonomy, Mastery, Purpose in motivating us to do good work. And McGregor’s work in the 1960’s developing theory x and y of management has helped us understand some of the management thinking behind creating a false sense of urgency. And then there’s the critique of the “twice the work in half the time” notion that agile is synonymous with working faster, which is or isn’t true depending on how you look at it. Basically, speed is a complicated concept. I think teams need to know how to go fast before they can make choices about setting the right speed in different situations.

And I thought about:

Ernest Dichter is the father of user research

You know how I like to get to the source of things (boundary objects are the source for user stories, this paper is the source for the big product risks)? Well, I wonder if the field of user research and product discovery has it’s roots in the focus groups and consumer behaviour analysis that Dichter created in the 1950’s. Dichter took observational research methods from psychology, applied to businesses, and used them to understand the beliefs and attitudes that explain why people behave the way they do. This new understanding was used to create the advertising industry, which Dichter has been heavily criticised for, but it’s also what gave rise user research and product discovery. It’s interesting that techniques developed to manipulate people seventy years ago are still being used today under the guide of being “user-centred”. I wonder how much has changed.

Looking around

I’m tending towards accepting the success for teams, products, services and probably entire organisations is mostly down to how they notice and respond to what is going on around them rather than within them. When we look around outside and bring what we see back into the organisation, we create a porous membrane. The hard bit is knowing what to do with that information, figuring out what is relevant, deciding how to respond to it. That’s the challenge to success.

This week I did:

Keeping the lights on

I did some process design work to figure out how to manage some operational processes to manage all the third-party services our team uses. Also, thinking about these processes from the perspective of the technology and data strategy work I’ve been doing. In a way, that’s the test of a strategy, that it is not only about the big impressive stuff but that it enables the utility processes that no one wants to take any notice of. This is the kind of vertical integration I talk about in my product management in charities emails.

Product environment

I’ve been gradually working on defining the aspects of a product environment that are required for product managers to create products that are valuable, useable, feasible and viable. It’s like a flower with unfolding layers of petals that go deeper into the product environment. I think the repeating patterns of four circles and of concentric circles suggest different things going on at different layers but it needs lots more thinking.

I read:

Cheating

John Cutler’s very cool product cheat sheet is an insight into a post-agile world of product development where more teams actively create their own way rather than trying to follow out-of-context frameworks. He describes it as, “We place BETS to influence MODEL elements (where we can have most leverage), understand progress by setting and reviewing GOALS, use MEASURES to refine our MODELS and ground our GOALS, and support all this with RITUALS/PROCESS. All models are developing hypotheses.”

Objecting to Objectives (and Key Results)

And continuing with a theme of critiquing no-context frameworks that only work is specific contexts, I agree with Jukesie’s post on not trying to fit OKRs where they don’t belong.

Evaluation as a service

James Higgot’s excellent explanation of an opportunity pipeline and evaluating the opportunities is really interesting as I’ve been doing a bit of thinking on briefing incoming work. I wonder how information on an opportunity canvas is compared with another to choose between them?

The State Of Usability In 2023

Smashing Magazine describes how people behave on the web in 2023. It includes observations from real usability testing on what people do and what they don’t do on the web. It’s interesting how most of the things people don’t like are those that get in the way of them reading content on a web page.

And I thought about:

Working backwards or working forwards

What the best way to approach product development? In which situations is it better to start with discovery in the undefined problem space and move forward towards more certainty as the solution evolves. And which situations is it better to start with the certainty of the outcomes we want to achieve and work backwards to figure out what we need to do to reach it?

Starting with outcomes, creating an assumed theory of change and working to validate those assumptions before identifying and building a solution that achieves the outcome, feels like it enables more and shorter feedback loops than following the DABL process, which is essential for learning.

Purpose

If roles had a core proposition, or core problem that they solve for an organisation, what would they be? For Delivery Management, maybe it’s facilitation, and for Product Management it’s validation, perhaps for Project Management it’s accountability. Maybe starting with this core proposition could help organisation build up teams with clarity of purpose

This week I did:

Quicker validation

We tried a couple of experiments this week to speed up how we validate meeting a user need. There are two parts; getting a solution in front of real users quickly (in hours rather than days or weeks) and setting the measures to know whether the solution is meeting the core user need. If we get a positive result from the experiment, then we’re in a good position improve the solution, and if not when we’ve learned quickly without a lot of effort. Shifting thinking from ‘right first time’ to ‘right over time’ means accepting a lot more uncertainty and imperfection in order to learn more quickly, but in lots of cases it’s definitely worth it.

Will technology create a better future?

The answer is by no means certain. The tech-optimist perspective isn’t rationally defensible, but there is some suggestion that an agency-based perspective that says tech will make things better if we actually decide to make tech make things better could be a good way to go.

And I read:

Calculated Risk: A Framework for Evaluating Product Development

This article in MIT Sloan Management Review from 2002 talks about the limitations to traditional financial risk management approaches and introduces a framework for considering market risk, technical risk and user risk. I wonder if this is the source of the thinking about the ‘four big risks’ of value, desirability, feasibility, viability. I like getting the source of ideas (like how boundary objects are the source idea for user stories), not only does it help to understand how ideas change over time .

Learning reviews

Apart from doubleloop looking like a very cool business data visualisation tool, this post on conducting learning reviews . In general, it asks, ‘what assumptions did you have eight weeks ago and what do you think about them now?’ If retros look back at how the team worked and what they could improve, and traditional reviews look back at the work completed, this kind of thinking (and tool) reviews assumptions and hypotheses about what drives metrics. Doing all three regularly feels like it might help teams improve on the how, the what and the why of work.

Bringing Scientific Thinking to Life

Improving rational, objective thinking that is an essential underpinning to good practice and process, and especially for product managers.

Thought about:

What makes products successful

I been thinking about what are the biggest factors in the success of a product. I haven’t found any good research to answer the question yet, but it seems that one of the biggest factors is probably how well a product fits into the market and culture and one of the smallest factors is what process the product team uses to create and manage the product. Interesting then how much product managers talk about tools and techniques and how little they talk about ongoing horizon-scanning, market analysis, and thinking about what things are changing in society that might affect their product. Obviously a product team needs to have all the things it needs to be able to do something about changes and opportunities, but they have to be able to see and understand them first.

Delivery management and product management

Been thinking a bit more about how delivery and product compare, contrast and work together. They are both about behaviour change, delivery for internal teams and product for external users. If delivery’s overall purpose (for want of a better term) is about ‘facilitation’, then product is about ‘validation’.

Did this week:

Data strategy

I’ve been working on creating a framework and project process for some data strategy work. The framework has three dimensions. Thirteen ‘strategic themes’ to tie the work to the organisational roadmap, five ‘use cases’, which describe what we do with data; generate, collect, manage, analyse and utilise, and six ‘change areas’; leadership, skills, data, culture, tools and uses. This gives us 390 intersections where we can make improvements.

The project process uses an improvement kata approach to understand a challenge, identify the current condition, define the next target condition, and then experiment towards achieving it. This approach gives us the greatest flexibility to experiment with improving things at each intersection of the three dimensions without getting blocked by other projects and dependencies.

Read:

Kanban Pocket Guide

I’ve started reading the Kanban pocket guide. The first chapter talks about how the most important aspect of Kanban, more important than limiting WIP or visualising work, is item age. The longer an item is hanging around not being delivered, the longer it takes to get feedback on it to find out if it’s of value.

Agile vs. Waterfall (And Other Obfuscation)

Increasingly, I dislike the duality of agile vs. waterfall. Both are just techniques which fit organisational environments to greater or lesser degree. And as Charles Lambdin says, the goal is delivering value, not being agile. His post refers to agile vs. waterfall as alternative options vs. path dependency and sums up a lot of current good practice thinking in achieving business agility.

Failing like a scientist

I’ve thought for a while that product management is the application of the scientific method to an organisational context, so it’s interesting to read a post about viewing failed experiments (which is only one step in the scientific method) differently from the traditional view of failure as an end state, after which nothing more should happen.

Thought about:

Muda mura muri

I’ve started reading about the three forms of waste to help me figure out how they apply to knowledge work. I think maybe context switching is motion waste in muda, and confusion is definitely some kind of waste, but I’m not sure which type, maybe muri.

Three-dimensional visualisation

I’ve noticed a pattern in my strategic systems thinking that visualises the work in three dimensions. That makes it harder to show other people or explain how it works, but essentially it’s like a big Rubik’s cube where you can find a single point by following the x, y and z axes. The three axes in the data strategy thinking I’ve been doing are ‘strategic theme’ (volunteering, people, etc.),and ‘use case’ (generate, create, manage, analyse, utilise) and ‘change area’ (leadership, culture, skills, tools, data and uses). So, by picking from one of each we create a piece of improvement work, for example, ‘Improve volunteer’s data management tools’.

Listening to Melvin

Fifty five years ago Melvin Conway warned against shipping the org chart. Today, we’re still doing it. Doesn’t matter whether the marketing team is separate from the product team or one cross-functional team is separate from another, not working in silos seems almost impossible. But what makes a silo? Maybe it’s whatever defines a team, things like identity, belonging, incentives. Where these things differ, lines are drawn, boundaries are established, and silos are created.