Weeknotes #257

This week I did:

Blueprinting

I spent quite a bit of time creating blueprints for how parts of products might interact as a way of exploring the translation from programme design into product development.

Service blueprint

In some ways, it was a week of visual working. We’ve been talking about how we do documentation better so that it’s quick to produce and easy to understand, and settled on screenshots being a good place to start. And one of the project teams is using Trello to track their work. I think, at the back of my mind, I’m taking onboard a comment someone made in the DigiScot talk about async working when we we’re talking about how we replace meetings, that drawing and visually representing ideas is a useful alternative to writing, so although I still write a lot, I’m trying to also work more visually so that more people can be involved.

Digital governance and risk management

I joined a really good talk by BeMoreDigital & Beyond Profit about managing digital risk and governance. I’ve been thinking for a while about how things like governance and risk management in charities, which are done in traditional non-digital ways, so it was really helpful to see others thinking about it. Governance is part of the business model of charities so as those business models become increasingly influenced by the internet, its important that we think about different ways of doing things like risk management.

Charity product management emails

I finished the first iteration of my ‘Interface – Integrate – Iterate‘ emails series about why charities need good product management. Next thing on the list is to get some feedback and figure out what improvements I can make. My aim (at the moment at least) is that this might develop into a project for after my dissertation about how to get good product thinking into charities.

June retro

End of the month. Time to look at the delivery plan I set at the beginning of the month and see how much I achieved and plan for what I want to achieve next month. Although this is only the second month of following a monthly process of reviewing progress and setting new goals for next month, it seems to be working really well.

And I thought about:

Influence

All a product manager has to get things done is their influence. And when something happens that damages that influence, even if it was out of the PM’s control, the thing to do is get to work on building up that influence. Vaguely connected, at least in my mind, is how this shows as a micro version of internet economics with attention and reputation being the currency. No one on the internet has authority over anyone else, but lots of people have more influence than others. So, for digital ways of working, whether on the internet of within an organisation, building and managing influence is important.

Consequences

I’ve been thinking about linear processes for product development (since that’s kind of what my dissertation is about) and how communication works throughout the process. I think there is a kind of entropy at play where well-ordered ideas and become more disordered at each stage as they become designs and then code. It’s a bit like playing a game of consequences where each time there is a hand-off to a different team, what was produced is hidden from the next and they only have the contextual rules of the game to guide what they then add. So, I’ve been thinking about how to reduce the entropy that occurs throughout the product development process.

Competition on the internet

My Twitter is made up of three ‘worlds’; charities, product management, and creator economy & nocode types. I see myself, one day, contributing to bringing those worlds closer together, but in the meantime I learn a lot from being part of these worlds. The lessons I learn from how the creator economy understands how to use the internet help me think about how the charity sector uses it internet (not really a spoiler but its way behind and doesn’t understand nearly as much). ‘Competition’ is a good example of that. The creator economy people know that they aren’t in competition with each other, even if they are doing very similar things, because they have an abundance mindset (something the internet has enabled). The charity sector, on the other hand, still has a scarcity mindset that drives competition. Competition works fine for usual market dynamics because the forces that drive it are mostly hidden, so everyone expects to be in competition but no one really knows who wins what. The problems occur when competition takes place in internet spaces which are more public, because then it’s easily taken as an attack.

And read:

Assemblage Space

I read John Willshire’s email newsletter Artefact 229 where he talks about his idea of Assemblage Space as a tool for thinking about the future and where our ideas about what the future might hold come from in our past. I was particularly interested in ‘the narrow now’ as the gateway through which how we remember the past and how we think about the future goes through. It helps us be aware that we are coming from a particular perspective, but it doesn’t help us see that the narrow now is always moving towards the future. Its the metaphysical conundrum of whether we conceive of time as a continuum or a series of fixed moments, but as John says in the video about A Spaces, the cone isn’t really the thing to focus on: the thing to focus on is the groupings of the things in the cone and how they relate to other things.

Lean impact

I read some of Ann Mei Chang’s Lean Impact which talks about whether/how innovation methods such as build-measure-learn loops can be used in the not-for-profit and social good space. There are some unique and obvious challenges about how impact projects are funded which make learning and scaling impact more difficult, but as Brid Brosnan from the British Red Cross shows, it is possible and it is changing.

Andragogy

I stumbled across the concept of andragogy, which is the theory of how adults learn from Macolm Knowles. Knowles said that when adults learn they should be self-directed and take responsibility for their decisions. “Andragogy makes the following assumptions about the design of learning: (1) Adults need to know why they need to learn something (2) Adults need to learn experientially, (3) Adults approach learning as problem-solving, and (4) Adults learn best when the topic is of immediate value.” So, adult learning programs should take these things into account.

Weeknotes #251

This week I did:

Rethinking risk

I spent some time this week working on how we think about risk, and start to recgonise that estimating and quantifying the likelihood of a risk occurring isn’t a very helpful way of thinking about some risks. For some risks, the kind of risks where even a single occurrence is unacceptable, severity is what matters. The tendency of likelihood-focused thinking is to assume that risk can be mitigated to point of being extremely unlikely to occur, and so severity doesn’t matter. But severity-focus thinking assumes the risks of high severity are always high severity, however likely or unlikely they are to occur, and so either need to be accepted or removed entirely.

Rationalising requirements

Of course no product manager should just be taking business requirements and handing them to the development team to build without some rationalisation and validation, but I’ve been spending quite a bit of this week figuring out what a structured rationalisation process might look like with getting caught in a bootstrap problem. Our programme design teams want to add something to the courses we deliver, and that thing requires some costly and complex technical development, which we don’t want to do unless we’re sure it’s going to get used and so we ask questions about how people might be trained in using this new feature, how many people might benefit, what is the total value, but of course those are hard questions to answer with only an idea of something to add. So where to start, that is the question.

A porous membrane for the organisation, and why it matters for product thinking

I’ve been thinking for a while about how and why the boundary between an organisation and society can be made porous to allow for knowledge to flow both ways. Whether this is Friedman’s nonsense about the purpose of a company or Macleod’s ideas about how organisations use blogging and social media, or how technology products act as interfaces between organisations and customers, the nature of the relationship between organisations and society is changing.

Simple machines

I went to a launderette and used a change machine. I’m fascinated by simple machines like these that have a very direct logic about their interface and require the people using them to make the decisions. Most of the software we use is other people’s decisions.


And thought abut:

What problem does Product Management solve?

A colleague asked me about what I do as a product manager, and as usual I struggled to articulate anything more than, “whatever I can to help the product be a success”. Generally, the usual explanation of being at the intersection of technology and what we can do with it, business objectives and how we achieve them, and customer needs and how to meet them, works but doesn’t help anyone understand the what or how of product management in a charity. There’s acceptance that there are lots of overlaps with what other roles do, there’s some business analysis, technical architecture, UX design, customer support, etc., but what does product management do that is unique to product managers? Or to put it another way, what problem does the role of a product manager solve for the organisation?

Change isn’t failure

Making a decision that was right at a point in time but, having learned more since then that makes that decision now look wrong, doesn’t actually make it a wrong decision. It’s better to make a new decision based on new information. Not making a new decision, continuing with the old decision, is more wrong now than the original decision. How we frame learning and making new decisions not as failures and changing minds, but as progress and the mark of good leadership in a digital organisation is a challenge.


And I read about:

Team topologies

I listened to a podcast about Team Topologies and patterns that help organisations achieving a fast flow of change in order to be more successful at software delivery. The three key principles they talked about were: Optimising for faster flow in live systems, using rapid feedback from those live systems so teams can course correct, and limiting team cognitive load. These allow teams to assume end-to-end responsibilities and develop solid practices. I’m definitely going to learn more about this.

Rethinking the ‘rainy day’ myths of charity reserves

Charity reserves are an interesting thing. There’s a lot to rethink and and lot of perspectives to rethink from. In start-up terms, it would be called a runway. It’s how long the organisation can operate before it runs out of money. For a charity, and more so for the people who are helped by the charity, the length of that runway is even more important than for most startups. Thinking around reserves crosses-over with the financial literacy of the trustees running the charity, the appetite for risk vs. interpretations of responsibility for overseeing the correct running of the charity, the types and sources of funding available, how many people are paid employees of the charity. All of these things and more should inform each charities position on reserves. It’s a more complex calculation than blanket guidance of x number of months operating costs can cover.

Direct Acyclic Graph

DAG’s are the latest and coolest implementations of Distributed Ledger Technologies. They tackle many of the issues that the sequential DLT’s such as Blockchain suffer from (although of course have their own downsides). As interesting as the technologies are, and s interesting as the use cases for the technologies are, I think the most interesting thing is how the ideas behind the technologies are going to affect our worldviews. We haven’t even figured out how the technologies of the internet have affected us, and here we already experiencing very different concepts.

Risk assessment by certainty of cost and value

Risk assessment by certainty of cost and value

When assessing the risks of a new piece of work the questions should be around how certain are we about the cost and value of the work. The more certain we are about the cost of a piece of work and the value of the outcomes, the lower risk of the work. This leads to prioritising more certain work over less certain, and making more uncertain work less uncertain.

Agile Risks Meetup

I went to a meetup with a group of Agile practitioners discussing Agile ways of dealing with risks. It gave me lots of interesting things to think about:

  • Get close to the customer, really understand their needs, to reduce the risk of building the wrong thing.
  • Users who are choosers give helpful feedback because they can decide not to use the solution. If not, feedback is superficial.
  • Explore possible solutions concurrently before going on to build a single solution.
  • Ignore the likelihood of the risk and focus on impact.
  • Communicate risks and issues sooner rather than waiting until they become big problems. Don’t pretend to be green if things are really amber.
  • Deal with risks as you go along rather than identifying and only intending to deal with only if they arise.
  • Risk reduction = knowledge acquisition.
  • Learning about the risky things is building business value.
  • Traditional risk management focuses on ‘known unknowns’, but misses the ‘unknown unknowns’.
  • Unknown things often get put to bottom of the list but maybe they should be dealt first.

From working with an agency to working with a freelancer

Another example of figuring out how to work in a more Agile way in a risk-averse culture.

When you’re risk-averse, finding the right agency takes months. You follow the Procurement Policy, go out to tender to get five responses, do Dun & Bradstreet assessment, negotiate the contract, and then eventually you get to work.

When you embrace the uncertainty, finding a freelance developer takes days. You message a few on LinkedIn, have an informal phone interview, pick which one can do what you need and get them started.

There’s risk in moving from building a website with a reliable agency who you can have faith will be there tomorrow and next week and next month when you need them, to using freelance developers who can move on and take their knowledge with them at any time. So, how can you manage this risk?

Embracing the uncertainty, you make decisions quickly with what information you have, you break the work into small chunks, do a few pieces of work and then decide what’s next rather than creating a plan at the beginning of the project.

Will it work? We’ll find out over the next few months.