Had an interesting chat about digital product strategy with a colleague.
Finished the third FutureSkills email and started the fourth.
Listened to Webflowers and Product Management: What is the job, really? – Christian Idiodi.
Went for a walk on the beach.
Posted an idea for a different way to think about org charts.
What if hierarchical organisation charts were replaced with a chain of who solves problems for who going from the CEO to the users.
Went for a walk on the beach and saw an old abandoned lighthouse.
Wrote and sent the 7th Irregular Ideas email newsletter.
Bought systemshiftingproduct.management domain name and pointed at the Google Doc.
Worked on the third future skills email.
Tried to focus on writing the third email for Future Skills but kept getting distracted by Twitter and other little ideas. Wondering if I should spend time trying to grow my number of followers, but to what end? Maybe with the Twitter Product Manager community in case I ever do write a book about systems-shifting product management. I’m just not sure anyone else would be interested in it as most of them seem focused on the day-to-day tactics of product management.
Photo of the week:
This week, I did:
I mapped user journeys specifically for evaluation purposes, and it got me thinking about whether and how the evaluation of programmes that aim to achieve considerable life changing outcomes can be part of feedback loops. Intuitively, it makes sense that small outcomes have small feedback loops and large outcomes have large feedback loops. But a few things to remember: the aggregation of lots of small outcomes doesn’t necessarily equate to a large outcome, evaluation can be linear and not feedback, and it’s easy to evaluate different things than those that might change the outcome.
And speaking of using feedback loops better, I presented the solution design work I’ve involved with to the developers for their feedback on the feasibility of the ideas. It was really useful and has meant I can creating two solution designs that are more right-sized for what they’ll need to achieve in different circumstances. Such is the benefit of sharing incomplete work early for fast feedback.
I did some more work on Future Skills emails. I complete the second email which is about fluency of ideas, the skill of coming up with lots of ideas quickly. I wrote this email far more quickly than the first so my hope that setting a template would make the content easier seems to be working. We’ll see for the next email which is about active learning. I still have a long way to go to create all of the emails but I think I’m going to focus on this for December rather than spreading my time across other projects like Systems-shifting product management and future.charity.
As it’s the end of November and beginning of December I did my monthly retro and delivery planning. My lesson from November was about how aiming for simplicity has lots of benefits. Complications slow down progress and drain motivation. In an attempt to make the most of this lesson I’m going to try to focus more time in December on just one project.
And I read:
More and more I think the solution to digital, remote, asynchronous working (DRAW, as I might start calling it) is going to be about how we mix and mesh different models, frameworks and practices. One of those things to figure out is how we measure the progress of work without having to be limited to a single way of working that provides consistency in reporting. Kanban metrics focus on how “cycle time that deals with the average amount of time taken for a task to move from start to finish. Improving cycle times by removing waste and blockers help to achieve improved results.”
Following on from completing the Humane Tech course, I read some stuff from Humane by Design and Ind.ie. The pyramid of technology that respects Human Rights, Human Efforts, Human Experience is interesting, and “resources that provides guidance for designing ethically humane digital products through patterns focused on user well-being” are really useful.
I read lots of stuff from Tiny Little Business, including The Durable Business Course.
I thought about this week:
Pieter Levels tweeted about shipping fast by building light which prompted me to think again about how I priortise the things I want to work on. I’ve tended to focus on things that interest my rather than things that might be of value to others. Honestly, even if I do figure out how to create a DAO charity, no one is even going to be interested let alone pay for it. The usual way creators figure what to build is to build for their kind of people. Developers build things for other developers. Remote content designers build things for other remote content designers. As a charity product manager there aren’t enough of us. I’m too niche. The answer, perhaps, is to find things that interest me and are useful to others.
I was thinking about autonomous teams and what it takes to get there, and how leadership works for high-performing autonomous teams. Teams have to have leadership. The ideal for autonomous teams is that the leadership exists within the team. For non-autonomous teams, leadership should come from outside the team, from above. But what happens when a team doesn’t have either. A team without leadership is an abandoned team, left to get on with things without direction or cohesion. I’ll probably write up these ideas into a blog post if I get time.
Or DRAW, for short. I’ve been thinking about some of the problems we’re all trying to figure out for effective digital, remote, asynchronous working. Things like communication, alignment, coordination of work, etc., all need to be revisited and reworked. Just applying the old ways isn’t going to work. It seems like there’s a good market size there but I stopped myself from buying the domain digital-remote-async.work. I should focus on finishing current projects rather than starting new ones.
Lesson of the month is ‘simplicity’. However big and complicated something is, pulling out the simplest small part of it is the fastest way to progress. Sometimes things like complicated just because they aren’t well coordinated. Simplification makes coordination easier too.
It’s been a interesting month of moving from definition to the development work. I always know that the transition is never straightforward and clean cut like all the models show but I still get slightly surprised by it. Project phases are an illusion.
I didn’t get onto the work I was expecting/hoping to do around the continuous improvement model for the product but I did progress the decision around the use of virtual meetings platform. And as always, I did lots of other things.
I resigned from my role at the Prince’s Trust and am joining RNID as a Product Lead.
I’ve pretty much given up on the idea of innovat100n.com. FutureSkills.info is a more interesting idea with better defined audience and at least some idea for a potential marketing plan, and I’ve already made more progress than I ever did with writing a hundred essays about innovation.
I’ve enjoyed writing the Irregular Ideas newsletter for the past five weeks. Being a newsletter rather than blog posts adds some constraints which I think/hope are improving my writing and I like that it has a broad topic.
I didn’t add any more stiles as NFT’s. Just wasn’t a priority. It would be nice to get all of my stiles on Opensea but it’s very time-consuming I don’t know what I’ll do with them once they’re on there.
I did a bit of research into DAO’s for future.charity but not enough to really progress the idea. There is still something really interesting to explore there but it’s big and messy and amorphous and very uncertain.
I wrote quite a few blog posts for NoBloPoMo but not the full thirty I was intending too. I decided to refocus on other projects.
Didn’t do any work on Adjacencies and losing a bit of interest in it.
I finished the Foundations of Humane Technology course. I want to try to embed some of the stuff I learned in my product thinking so I might write a blog post about it as a way to start to collect together some thinking about humane tech.
I wrote weeknotes on schedule every week.
My nomadic life along the coastline continued. The weather and dark evenings haven’t stopped me from visiting beautiful places each day.
Users at the centre.
Understanding needs and problems on one side and outcomes on the other.
Acquisition and Solutions intersect the Users to show that equal consideration needs to be given to getting people using the product as building it.
Below the line of user interaction is Costs, Partners, Resources and Funding.
Doesn’t have Activities like iteration 1 did. Should it?
Photo of the week:
On this week’s Done list:
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.
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.
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.
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:
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.
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.
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:
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.
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:
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.
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
Definitely letting go. Still a challenge, probably always a challenge, but an important lesson to learn.
This week I did:
I started doing some solution planning work for the next few months. It will hopefully bring together the strands of work that we’ve been building more recently. It’s like the plot reveals in a detective story where we can start to see why that decision was made back then and why we wanted to do this other thing that way.
Sent my third Irregular Ideas newsletter and got my fourth subscriber, but still have no clue about solving the feedback loop problem. The newsletter is supposed to be about sparking ideas together, but maybe my ideas don’t connect with other people’s, or maybe most people aren’t interested in ideas as a unit of value in the way I am. Maybe it needs a lot more subscribers and then a call-to-action to ascertain whether it’s solving that problem, but I think it’s probably just too amorphous a problem to measure in that way.
I caught a bit of the talk Andy Tabberer did called ‘Human side of delivery: forging relationships & building trust in a remote world’. It was good to learn a bit more about delivery management from the people side rather than practices. In a very simplistic and tactical way I’ve always seen delivery management as being about removing barriers for developers but I found the idea of ‘team health’ interesting and it made me think about what that might mean in different team contexts.
I’ve started doing a bit of research into how a DAO could be set up to run as a charity. There’s a lot to think about (that’s an understatement). There are barriers such as DAO’s aren’t a legal entity, and they rely on being able to codify the rules of the organisation, which is difficult when charity law is so messy. But there is also lots of interesting potential to explore for how each of the functions of charity might work in a tokenised system.
And I thought about:
I’ve been thinking about how difficult it is to conceive of and describe how different teams within the same organisation interface with each other. I think there’s a difference between teams interfacing with other teams and functions affecting teams, so for example the HR team manages the payroll function, but they aren’t interfacing with any other team as part of their work, payroll happens for all teams equally and so without any particular affect. Interfacing affects all those that interface. Some teams have clearly defined roles, responsibilities and practices, and I wonder if when they interface with teams that are less well defined, that their ‘harder’ boundary is more likely to push the more flexible team out of shape. How teams interface, and the shifting interplay of that interface, could be a systemic cause of friction or lubrication. How well teams understand their place in the organisational systems, however implicit that understanding (because it’s not as easy to depict as an org chart) must also be important for working effectively. It isn’t as simple as saying, ‘this team’s role is to do x’, because that speaks of the team in isolation and not in relation to other teams. Maybe value chain mapping could help to see where and why teams interact, even if not quite how.
The usual flywheel business models, as described by the uber napkin drawing, show how different aspects of a business drive others and that growth comes from increasing the throughput of the flywheel. But that are always shown as closed systems, in isolation from any other systems they might interact with. I’ve been wondering if multiple flywheel business models might interact with each other in an eco-system of business models. The difference between flywheel and linear business models is that flywheels feedback into themselves whereas linear takes an input, processes it and outputs something of value. I haven’t yet thought of an example of flywheels interact, either to drive to flywheel or slow it, but I’ll keep thinking about it.
I’m still thinking quite a lot about what systems-shifting product management might look like. One of the ideas I’m playing with to shift the focus off user-centred design and to achieve outcomes by causing changes in systems is to affect the people who affect people, or, to put it another way, work on second order personas. For example, if you wanted to improve the experience someone with disabilities has when interviewing for a job, you can provide them means for overcoming barriers (first-order persona) or you could provide employers (second-order personas) with the means to remove barriers and so change a part of the system.
I’ve been thinking for a few weeks now about the two opposite ways of approaching problems; engineering thinking, which solves known problems with upfront design and results in repeatable solutions, and design thinking, which solves less certain problems by uncovering the way forward step-by-step and results in more unique solutions. In thinking about critiques of these approaches it occurred to me that the design thinking approach could be seen as ‘throwing mud at the wall to see what sticks’. It then occurred to me that uncoordinated haphazard attempts to solve problems might actually be an entirely different approach, which then places all three on a spectrum from unplanned to planned with the design thinking approach somewhere in the middle.
And this week I read:
World Building is about story-telling. But it’s about more than that. It’s about how everything connects with a purpose in a coherent way to create the story that exists when it isn’t being told. This is an inspiring idea. In thinking about a portfolio of products all centred around similar problems and users, the world we build shows all who enter it how things are now, where we’re going, and why it’s the right place to go.
On the theme of lots of small solutions being better for approaching complex problems than big single solutions, What’s the pont’s post about Trojan Mice as safe-to-fail probes into complex situations to gather data and make sense, is really interesting. I’m not sure I fully understand what the post is saying as it seems to be talking about replacing Trojan Horse projects with Trojan mice, but they serve very different purposes and so couldn’t be direct replacements, but it’s useful to think about how we might send . And to throw in another thought, clockwork mice behave in predictable ways but might collide in interesting and unexpected ways. Something to consider for multiple safe-to-fail probes.
This is an interesting post about charities position on the narrative about the overhead costs charity’s have on many levels. I wonder where justifying low percentage of overhead as a good thing started. Was it in response to a genuine problem or hype and moral panic? As the post says, those charities that spend most of their money on what would be considered overhead, because of the type of work they do, become disadvantaged by that narrative pushed by the charities that don’t spend in that way. The specifics of overhead aside, it raises interesting questions about where charities draw the line in being competitive or collaborative. In what circumstances is it ok for a charity to do what’s best for itself rather than what might be good for the sector? And when should a single charity disregard it’s own best interests in favour of the sector benefiting more generally? If a charity makes a choice that results in it having less funding and so being less able to achieve its objectives, isn’t that bad for the sector as a whole? It’s a complex issue.
My growth area this week:
I’ve been thinking about ways in which we ask for help when we don’t know how to ask for help, or don’t realise that we want help. Maybe it relies on other people recognising changes in behaviour, but sometimes there just isn’t any way to help.
