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.
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.
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.
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