Weeknotes 464
I did:
Never finished
A fairly practical conversation about ways of setting up ADO turned into a philosophical conversations about the difference between the project and product mindset, particularly about how products are never finished and our tools for managing products need to reflect this. Also this week:
- Designed a workshop to turn strategy into action plans.
- Wrote up a simplified version of a product strategy to get feedback.
- Took part in a workshop on how better manage lines. People over process was the general consensus.
- Wrote a user guide to OKRs to help product teams align their work to the group strategy. My challenge was designing the way we do OKRs to be as lightweight as possible but still give us the benefits of focus, alignment, autonomy, etc.
- Watched a session on architectural decision records and the process in github for generating Word docs.
- Got pimped out to other teams (Kidding, I enjoy helping out where I can).
- Looked into long-term impacts of using AI, especially on strategic alignment and financial investment, which could be summed up with the phrase, “you get what you pay for.”
Other things that’ll never be finished
Started writing blog posts I’ll never finish. One on the economics of AI in higher education looking at how costly it’ll be for universities to adopt AI (because it’s a volume play with poor ROI for orgs with a low number of actions AI can do). Another on use cases for AI in product management using the six use case primitives and applying them to different product activities, essentially building on the idea that AI is good at solving problems that have already been solved and making the case for getting rid of repetitive work so we can focus on creative thinking about novel problems.
I read:
Pitch
Started reading Pitch by Danny Fontaine.
Exploring AI’s Role in Education
Lots of interesting ideas in WAO’s thought-pieces on AI in education.
Let’s debunk a myth of Now-Next-Later
“What the time horizon roadmap gets you is the flexibility to show deadlines and milestones where needed, and never get trapped by showing a bunch of arbitrary deadlines.” I’m still not convinced, but Janna’s the expert so listen to her, not me.
Feedback Is Not an Attack
“Feedback should be thoughtful, specific, grounded, and mutual. If you’re not doing it with intention, you’re not doing it right.”
(Also I added Ashley’s blog to my feeds along with about a hundred other writers, bloggers and weeknoters)
Discovery and delivery are different
Ragan McGill is right. This brilliant post describes some of the ways product discovery/development and delivery are fundamentally different, and how applying the thinking of one to the other causes problems. “Treating delivery like discovery is like running scientific experiments on an assembly line – it slows everyone down. Treating discovery like delivery forces premature decisions and suffocates learning.” If you’re a product manager switching between them every day it’s no wonder things get confusing.
I thought about:
Unbundling university
One approach to innovation is the unbundling and bundling of existing products. The more an industry bundles together, the harder it is for an innovator to disrupt it by unbundling. Take higher education, for example. It bundles qualification and accreditation, knowledge and expertise, kudos and achievement, making friends, developing independence, networking, choosing a career, etc., etc. Now imagine trying to unbundle that and pick one aspect to innovate on.
That’s what the ‘YouTube is free university’ proponents get wrong, that just being able to watch a bunch of videos may impart some knowledge but that is one very very small part of what people get from university. If attending lectures and remembering information was all there was to university, higher education would be easy to disrupt. But there is so much more, and it’s all interwoven, and so well-established, that it really really hard to innovate on, especially for universities themselves.
Internal product life cycle
Internal product life cycle looks very different to customer-facing products. The usual product lifecycle shows the number of users going up through growth, levelling off with a mature product, and then a declining number of users is a signal to the business that the product is going into decline. But for internal products, the number of users isn’t a sign of success and decline isn’t signalled by lessening number of users. An internal product usually only comes to an end if the business changes what capabilities it needs, e.g., outsourcing payroll or closing down an ecommerce offer.
Measuring AI
The problem with the ‘using AI equals better efficiency and productivity’ narrative is it misses the nature of general purpose technologies. Asking and trying to measure the time or cost saving of using AI is like trying to measure the time or cost saving of using the internet or electricity.
The perfect process
There is no single perfect product development process. Obviously. The “right” process depends on the team, the product, the organisation, and so many other factors. I’m not a fan of overly standardising things that work better flexibly, and product development process is something teams should be allowed to decide for themselves. Sometimes, a process is implemented for reasons other than giving teams the best chance of developing great products.
The product of Theseus
What is a product? It is the sum of user interface, policies and business logic, technologies, budget, people’s knowledge and skills, etc., etc. Any single part can be replaced but the product continues to exist. In fact, over time, all the parts can change or be replaced and the product still exist.