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.

Weeknotes #225

What I did this week:

Scope

Defining scope is hard. Because you don’t know what you don’t know. We’ve been trying to reach a base-lined definition of what we should deliver in our current project. Writing a list of things is easy. Feeling confident you haven’t missed anything is not so easy.

Study

Qualitative interviews and transnational innovation. As with most things, the more you look the more you see. I thought qualitative interviews would be easy after the statistics lectures (and they are, statistics is still the hardest thing I’ve ever tried to learn) but of course there is lots to learn about how to make them successful. Transnational innovation is about companies moving into other countries, not to access another geographic region, but in order to leverage the innovation and learning potential that doesn’t exist in their home country. This is based on the underlying thinking that strategic success for companies in the 21st Century comes from developing and leveraging knowledge rather than capital resources.

Wipeout

I bought a wipeboard. The note-taking cult on the Internet says you should write everything down. Connect those ideas. Build on them. Don’t loose anything. I wonder if letting go of ideas might be ok. I’ve also been thinking about all the things I want to do, products I want to build, all those projects on my roadmap, and I wonder if the world really needs more poorly implemented digital products. Probably not. I’m becoming more essentialist in my thinking.


Thought about:

What is product management?

I think the product management function in an organisation serves three purposes: interface between the customer and the organisation, vertical integration between hierarchical levels in an organisation and horizontal integration between teams, and feedback loops between all of those. When organisations learn to organise in ways that achieve this without a facilitating function/role then Product Managers won’t be necessary.

BPAAS vs. SAAS

What’s the difference between Business Process As A Service models and Software As A Service models? I think the key difference is that BPAAS model requires inputs from the organisation using the service, whereas SAAS doesn’t it is just used. I think BPAAS has an advantage over SAAS, it has two opportunities for learning. It has the same feedback loop that SAAS has where the usage of the service is used to improve the service, but it also can help the customers improve their inputs and so get better outputs.

Ramblechats

I’ve been thinking about making videos. This might be driven by three intersecting things: My ramblechat with Bobi Robson, upgrading my phone package to give me unlimited data, and spending most of my time on work and study meaning I don’t have time to write blog posts. I thought I might go for a walk and talk to myself about some of my ideas, having a ramblechat with myself whilst rambling. It might be a quicker way to explore ideas in a non-precious way whilst pushing me outside my introvert comfort zone.


Reading and tweeting this week:

Inputs

I normally have lots of inputs. It’s part of my synchronicity of ideas. I listen to podcasts, read newsletters, scroll through Twitter, add interesting articles to my website, and write notes about all the inputs I have. This week I’ve hardly consumed anything other than what was on my reading list for lectures. At the other end of the process, my outputs are drastically reduced at the moment too. Lots of work and study means I’m not participating in the digital charity or maker communities I’m part of, not working on any of my side-projects. I’d like to structure my time better to make sure I get some time each day for this kind of stuff but its hard to justify when exams are only a few weeks away.

Reframe the challenges

Not feeling bad about failure is an important factor in trying things more times and so increasing learning.

Not a failure

“I have not failed. I’ve just found 10,000 ways that won’t work.”

– Thomas Edison

Learning from failure – experimenting with start-up thinking in charities

There’s increasing evidence that the traditional charity business model is being disrupted. It’s becoming harder to generate new income from mass fundraising. And new competitors are emerging to deliver social impact. According to Deloitte, 87% of Millennials believe that companies should do more than generate profit. In response, a new economic category is growing at lightning speed where profit is closely linked to social purpose (e.g. Belu, Elvis & Kresse, Change Please). What does this mean for the future of the charity sector?

The four R’s of Failure

Failure is closely aligned is Risk. Failure is what happens when we aren’t able to prevent the risk from manifesting. As we develop better ways to manage risks we should also consider the means for dealing with and learning from failures.

Resilience

Resilience is about preventing failures.

It requires:

  • analysis and prediction,
  • contingency planning, and
  • monitoring.

But:

  • how does Resilience embrace uncertainty and accept that not everything can be predicted or monitored?
  • how can failure be accepted as necessary for learning and be planned to be prevented at the same time?

Response

Response is about responding to and continuing to operate whilst a failure happens.

It requires:

  • broad knowledge of situation,
  • deep knowledge of the impact over time,
  • careful consideration so as to not make the failure worse,
  • priorisation, and
  • fast detection and early steps towards recovery.

But:

  • should we protect other work over prioritising dealing with the failure?
  • should an assessment of impact be the deciding factor over likelihood of the failure, and
  • should dealing with failure be a whole team responsibility?

Recovery

Recovery is about fixing the failure after it has happened.

It requires:

  • a plan,
  • resources to put the plansinto action, and
  • testing to be embedded in process.

But:

  • how do we maintain a close feedback loop with the Response phase to get the solution right, and
  • who should fix the failure, those involved in creating it or someone else?

Review

Review is about learning from the failure.

It requires:

  • documentation of actions, and
  • commitment and processes to make improvements to Resilience, Response and Recovery.

But:

  • how does it spread the learning,
  • and is it’s aim to prevent future failures or encourage them?

How we approach Risk and Failure is essential for fostering psychological safety, to enable rapid experimentation, to make people awesome. We tend to assume that failure is a result of fault. A fault occurs which leads to a failure, and if there is a fault then there must be someone at fault, someone to blame, someone who did something wrong or different. If dealing with failures is underpinned by this assumption then failure can never be looked upon as a positive. The best we can see is that at least the failure has been uncovered and fixed. And perhaps that is enough to drive some kind of iterative process of continuous improvement.