This week I did:
I was on leave this week so had more time to do some more thinking about the things we need in place to be able to tackle the four big product risks of not tackling a problem worth solving (value), creating something people can’t or don’t want to use (usable), not being able to build and maintain it (feasible), and not being able to resource and alignment to organisational strategy (viable).
The layer of things I’m working on is about establishing standards of quality, it doesn’t include processes and practices or team culture stuff we might do to understand and mitigate the risks. That’ll come later. So far I’ve focused on feasibility (because it seemed like the easiest) and usability.
- Data – We need some standards for data quality & integrity.
- Maintenance – We have to ensure we have the knowledge and skills to support the continued operation of the product.
- Manageable – We’ll have to be able to manage the tech, including supplier relationships if we use third-party services.
- Performance – We might use Lighthouse scores for this.
- Privacy – The product has to be able to ensure the privacy of users, not exposing their info to other users, services & organisations, etc.
- Reliability – Setting standards for infrastructure.
- Security – Prevent unauthorised access and attacks. I’m sure there are some standards out there along with best practice guidance on passwords from NCSC.
- Accessibility – ISO/IEC 40500 & WCAG (of course) but needs more definition based on the intended audience.
- Mobile-first / progressive enhancement – Not just thinking about how the product looks on a small screen but about how it will work with low phone signal
- Safety – The KCSIE’s 4 C’s of online safety; content, contact, conduct & commerce. Ok, it was designed with kids in mind but it seems like a solid place to start when ensuring online safety.
- Testing – Don’t know if there are any standards for product testing, but there must be some good practices.
- Usability – Maybe ISO 9241-11:2018, Ergonomics of human-system interaction can help.
I haven’t done much around what we need to ensure a product is valuable and viable, but I have some ideas about value involving understanding the problem and measuring the solution, and viable involving alignment with organisational strategy, budgeting and compliance.
Product management zone
I played with Softr and Airtable again to create productmanagement.zone, a directory of product management resources. Got lots to add to the database, and it’ll probably go the way of most of more projects, but I might actually try to get some people to use it and give me some feedback.
User-centred vs user-rhizomed
I wrote a quick blog post about the downsides of placing the user at the centre of how we think and design, and how we could use a rhizome as an organising structure for more varied thinking about how everything connects in the system we’re designing.
How Afrofuturism might provide a framework for thinking about technology charities
I’ve been meaning to write an essay about how afrofuturism might provide a better framing for how charities think about technology than the silicon valley tech-optimism that underpins so much of the tech sector. It turned out shorter than I intended (never a bad thing), but it’s good to get my thoughts written so I can build on them.
Design the Team You Need to Succeed
This is a really interesting article by Christina Wodtke shared her insights that;
- There many kinds of teams, and you should decide what kind you need first.
- Teams have stages, but it’s not linear. It’s iterative. Great teams are willing to storm, norm, perform, then storm again and re-norm in order to constantly grow.
- Teams need to consciously co-design the core three key elements of a team— goals, roles and norms — to be successful.
This mobile gaming report is really useful research for charities developing their gaming fundraising strategy.
“There are few better ways to visualise a product domain and develop a shared understanding of what a product does and how it is used.” I really like story mapping.
I’ve been thinking about the internal/external split in organisations, including Hugh MacLeod’s porous membrane, and what an organisation looks like that uses (as much as is practicable) the same ways of working internally with it’s staff and externally with it’s customers.
Reversing Brook’s law
I have a theory that the reason four day working weeks are so successful is that they reverse Brook’s Law. It isn’t (only) less time at work that creates the benefits, it’s that everyone spending less time reduces the coordination challenge by 20% which is a massive efficiency/effectiveness gain. I wonder whether the studies of orgs doing 4 days a week include measuring work in progress against when they were doing 5 days a week? Do the organisations make more/better prioritisation decisions because of the feeling of having less time? How long does it take for the beneficial effect of four day working weeks to wear off?