Weeknotes 476
I did:
Out of office
I’m pretty much always out of office because it’s the twenty-first century and I work for an organisation that’s smart enough to value remote and hybrid working, but this week I was also on leave. That means time for thinking about:
- What’s the difference between an internal product team and a platform team?
- What should be in an opportunity space mapping workshop? Or to put it another way, where does opportunity work end – is it with it mapped, on a roadmap for exploration, plus techniques for exploring, annnnd decision-making and reporting?
- How could impact mapping be made easier to work with so the logic of inputs to activities to outputs to outcomes to impact makes sense more quickly?
I read:
Responding to change
Interesting thoughts from Ian on teams being more intentional about the type of change they are using. Tacking is about knowing where you want to get to and course correcting along the way. Exploring is used to figure out your terrain and where you want to go. And following a plan for what and when to change on your way to a predetermined destination is the third approach.
Domain Driven Design
I read a few different things on domain driven design in preparation for some architectural discussions next week. Can’t say I’ve got my head around it yet but I can see how it will be helpful, mostly around how to organize large domains into a network of Bounded Contexts.
Techno-solutionism in education
Why does education keep falling for techno-solutionism, despite the fact that technology does not seem to drastically improve education? If you want my opinion, it’s the money. Big consultancies push technological solutions because they can be seen to have delivered something for their money, big tech companies push technological solutions because that’s how they make their money, leaders technological solutions because it gives them something tangible to ask for money for and stay relevant.
unFIXing Your Organization With LeSS
I can see how there could maybe be a case for organising in this way if there is a large number of teams all working on the same codebase and product. But in organisations that are smart enough to organise teams and products to be independent, the entire premise falls over.
I thought:
Think big, start small, learn fast
Six words to live by. A generally applicable approach to most situations of uncertainty where you have/want an ambitious goal and need to figure out the way forward by trying things. I don’t know if Chunka Mui came up with it or just got associated with/popularised it, but I’m grateful as it has been a guiding constant for many years.
Impact mapping metrics
I like impact mapping. It’s one of my favourite planning techniques but I don’t use it anywhere near enough. I was thinking about how you could add metrics to each of the five levels to understand how they relate to each other. Here’s a really rough example:
- Impact: Increase revenue by £3 million in one year.
- Outcomes: 50% of new users reach their aha moment in less than 2 hours = £1 million | Cohort of 1 to 5 days uses login more than 3 times = £0.5 million | Cohort of 6 to 15 days generate 1 report = £1.5 million.
- Outputs: Smoother onboarding process | Notification emails | Report templates and view-only access.
- Activities: Experiment and redesign changes for the onboarding process | Email trigger logic and new email content | Design templates, develop view-only sharing URLs, implement instrumentation.
- Inputs: £1 million team including designer, developers, product manager, tool licenses, etc.
If this was a diagram you’d see how each of the things on each level connect to other levels, but more importantly, you can see the team’s hypothesis for how they’re going to achieve impact in the outcomes, which helps them to focus on which outputs to deliver, which helps them decide which activities to do when. And, you can easily calculate the ROI of the team, and make adjustments such as investing more or less in the team, increasing or reducing time, etc.
University products
More rambling, connecting thoughts on defining products in universities (although it probably works in other types of orgs). It goes like this… products are the things the university provides, not the things provided to the university by IT or digital services teams (Couzens)… and we figure out what our products are by applying the business thinking of bundling and unbundling (Barksdale)… because universities are a big interconnected bundle of lots of things (it’s part of what makes them so difficult to disrupt from an innovation point of view (Christensen))… so if we were to unbundle it (we’re not, it’s just a conceptual exercise), we’d break off each business capability so that we can invest in it individually to create core competencies (Prahalad and Hamel) and we’d call them products… each would provide significant value to students, would enable the university to differentiate itself, and would have longevity that it means it can change and improve in ways that make it difficult to copy. Those products would include: Prepare to study (onboarding), Help & support, Library, Careers, Community, and many many more.