Weeknotes #200
I did some stuff this week:
Deliverables and requirements: which leads to which?
Should requirements be identified first and then used to define deliverables, or should the deliverables be agreed first and then the requirements defined to meet them? In the case of the things I’ve been working on this week, the deliverables came from the needs of the organisation to be able to work digitally with young people and the requirements came out of the technical capabilities of the products we have available to meet those needs. With neither of those two things negotiable the exploring of options in between has become even more important.
Solutionising
I’ve been getting into the details of solution architecting Microsoft products to understand how we can use them to enable volunteers to work digitally with young people. As Microsoft products are designed for use behind the walls of an organisation, are all interconnected in some non-obvious ways and don’t handle external users very well, it’s been an interesting exploration. One of the things I figured out is how to use Outlook to schedule Teams meetings for external users that meet our safeguarding, security and privacy needs, which I’m actually quite proud of (small things). When I’ve been writing requirements I’ve always given anything to do with safeguarding, security and privacy the highest priority and said that if we can’t meet these requirements there is no point even going on to functional requirements.
Feedback loops
As we prepare to roll out products to enable young people to get more and better support, we’re always working on training for those products, and whilst on a call with some colleagues I heard the phrase ‘feedback loops’. A big grin sprung across my face. I was so happy to hear someone else talking about modern ideas for how to build things. There was recognition that we have to make use of feedback loops from pilot users and early adopters to tell us what to include in the training to other users. Asking the people who are going to be trained doesn’t work because they don’t know what they don’t know or will need to know. Asking the product experts doesn’t work because they don’t know how the products will be used, only what they can do. But getting a small group of people to experiment with using the products and feeding back their learnings for others, that works.
And I studied some stuff:
How much is it?
This week’s lecture was about pricing strategies. We discussed lots of different ways a business can approach pricing the products and services they are selling (freemium, versioning, two-tier, etc.) but interesting nothing about how to choose the right pricing strategy. Since pricing is really just a proxy for the value exchange mechanisms between an organisation and a customer, thinking about how that exchange happens is really important and probably not thought about enough. If your business has something someone wants and they value what that gives them (do they really want a spade) more than they value the money it costs, then market factors such as availability, competition, etc., aside, both parties make the simple exchange.
For charities the value exchange mechanisms are far more complex. A charity offers something that certain people in certain situations value. Often, because of the situation they are in that causes them to value what the charity is offering they aren’t able to purchase that help, either directly from the charity or to find another solution, so the charity provides help at no cost to the person benefiting from it. But that service still has a cost. It has to be paid for somehow, and so the charity raises funds from donors, funding bodies, corporate partnerships, etc. Those that fund the charity don’t receive any direct benefit but they do get some secondary value from feeling good about their contribution. So here is a three way value exchange with more layers of value than a simple commercial transaction. Thinking of it in both those ways, the number of players in the value exchange and the levels of value those players receive would make an interesting mapping exercise.
And I thought about some things:
The Digital Charity
I started working on a long-form essay about what being a digital charity means and why it’s important. It covers how the internet and digital technologies have changed the way society thinks and are being weaponised to increase the inequalities in the world, so if charities are going to be capable of tackling these issues they will need to drastically change their approach to digital from thinking of it as a channel for marketing and being able to work from home to utilising concepts about how networks produce exponential change at a global scale, how people can no longer be thought of a simple biological individuals but are now complex socio-technical assemblages, and how unpredictable and often weird things arise out of the complex interactions in this new world.
Not enough whitelabeling
I see the current product landscape as falling into three main camps. They are enterprise products, for use within the walls of an organisation and generally don’t cross the boundary into the customer’s space, e.g. Microsoft. There are consumer products, such as Spotify, which are paid for and used by individuals. And then there are those products which are B2B products but are used by individual consumers, things like Magento and WordPress which are used to build websites that essentially become an interface between the organisation and their customers but are built by a third-party business. If an organisation wants to develop a product for their customers they pretty much have to build it. They might buy in services like identity management and payments but the functionality of the product will be developed, even though their product probably does the same thing as lots of other products. So, why it’s there more white label products available to businesses that they buy rather than build?
The no-code products like Bubble are edging this way but they are still more website-focused and aren’t at the enterprise-ready level yet. So, I predict a growing trend towards drag-and-drop product builders over the next few years that will enable businesses of all sizes to quickly buy in a product that enables them to build the product that meets their customers needs and is branded for them.
Looking at levels
I’m a big believer in loosely-coupled ecosystems of products that together meet the needs of the organisation to deliver support for young people, and give the organisation greater flexibility and adaptability because one part of the ecosystem can be replaced without disrupting the whole. But I’ve also been thinking about taking this approach to the capabilities level. So, for example we need a means of matching young people to mentors. On the product level we can buy in a mentoring platform that will meet that need. But on a capabilities level what we really need is a means of ‘matching’ different things. We want to match young people to mentors, young people to programmes, delivery partners to courses, etc., etc. I’ve thought a bit before about the logic behind how we match but the idea here of building a capability rather than buying a product (which clearly is different on two levels) is that it can serve a deeper need. With things the way they are at the moment, buying in products to meet specific needs is definitely the right approach, but I wonder where the threshold is for deciding the right problem to solve and right approach to solve it.
Updating my OKR’s
I’ve been updating my OKR’s to align with the shift in my life. So, out goes being a mental health carer and things that rely on me being in the same place regularly and in comes things about a more minimalist, digital, nomadic, hermit lifestyle. The three objectives of leading an intentional life, having an effective education, and having an impactful career in the charity sector persist but how I intend to achieve those objectives will change, which is kind of the point of OKRs.
And some people I follow tweeted:
Building a business on someone else’s land
Two of the people I follow, David Perell and Daniel Vassallo tweeted about building their business on Twitter. It’s interesting to me because it brings up the question of how much a business should control its supply chain. Paraphrasing Teece, the more of its supply chain a business controls the less risk it carries and generally the greater margins it can achieve. But in the modern internet world, is being on someone else’s land just part of the new business ecosystem, with the aim of getting email addresses so you can be in touch with your customers directly. In my weeknotes from last week I mentioned a renewed interest in email newsletters and some trends for email.
Prove it
Steve MacLaughlin tweeted, “The enemy of innovation is the mandate to ‘prove it.’ You cannot prove a new idea in advance by inductive or deductive reasoning.” A quote from Roger L. Martin. I can’t help but think that innovation’s association with failure hasn’t done it any favours. An entire business can be started speculatively without the need to prove future success, but as soon as it’s called an innovation its viewed with this ‘prove it’ mindset.