This week I did:
Small and independent
I was thinking this week about the value that small internal systems projects can deliver. By understanding the essential problems we’re trying to solve, and by using existing nocode tools, and with about a week’s work, we built a new tool to replace an old one. It’s free, which is cheaper that what we’ve been paying, it enables the team to adapt it as their needs change, it fits better with our open working ethos, and it puts us in a stronger compliance position.
Reducing costs and being compliant is important, but for me, the real value from this approach comes from the independence it creates. The system is independent, it doesn’t rely on integrating with other systems. And the team is independent, they are able make changes easily. More small, independent systems, I say.
Full loop product management
I wrote about what I’m calling ‘full loop product management‘ to describe what I think the whole job of a product manager is, and where organisations often go wrong. It’s kind of the product managers version of a full stack developer.
I completed 53 tasks across 11 projects. There were four projects that I didn’t work on. Tuesday was my busiest day with 16 tasks done. The project with the most tasks (9) is also one of the smallest projects and is getting quite a lot of focus because I want to finish it in August.
Systems thinking for product managers
My post on systems thinking for product managers is being used in a course for product managers. I noticed an increase in traffic the the page and tracked it down the a course website. I feel honoured.
And I read:
The unicorn project
I’ve been reading the unicorn project and I’m at the point where The Five Ideals have been revealed. I haven’t spent much time thinking about them yet, but I’m keen to understand why they are what they are and how I might apply them.
Making change happen
Nesta’s post on how to use different methods to make progress on big problems has some interesting insights, including “going deep enough but no deeper”, “it’s very easy to underestimate the opportunity cost of doing nothing” and “by paying attention to behaviours we can figure out what drives them”.
This is an interesting way to run pre-mortems. I definitely think we should have better ways of thinking about what could go wrong. We don’t have perfect foresight but there’s something there about using guesses to reduce the guesswork. Maybe the four big risks offers a way of theming all the things that could go wrong.
Reduce the risk of product failure
This post about reducing the risk of products failing by running experiments to validate value, usability, feasibility and viability is almost there. I feel like I need to rewrite it to have more focus on the experiments. Maybe one day.
And I thought about:
Product development metrics
- How long does it take us to go from starting work to making it live?
- How often does work go live?
- How much work goes live that doesn’t solve the problem it set out to?
- How quickly is work that doesn’t solve the problem fixed?
Good metrics balance each other to prevent over-optimising for one thing. So, a team that reduces the time work takes to go from idea to live by not validating that the idea is worth doing is going to see the amount of work that doesn’t solve a problem go up. The aim is to improve all the metrics together.
The remote/office argument reared it’s head on X again this week. I think it’s a silly argument. Organisations should intelligently figure out ways of working that achieve what they need to achieve. However, one of the big benefits organisations will see from remote flexible work in the coming years will come from making what Hugh MacLeod calls the ‘porous membrane‘ between orgs and the rest of the world, more porous. It opens up entirely new ways for information, ideas and value to flow in and out of an org, from economical in local communities to more lived experience shared which improves how orgs treat customers. It breaks down the barriers of thinking about orgs as only providing value to shareholders and starts to make them part of communities, part of real life. Orgs don’t only exist between 9 and 5, Mon to Fri, in one location, they can be better woven into the fabric of society.
The fine line
There’s a fine line between technology that reduces complexity for an organisation and technology that increases it. Avoid complexity at all costs. Thank me later.