Standards to assess products
Good products are:
- Accessible
- Cost-efficient
- Data usage
- Ethical
- Maintainable
- Managable
- Performant
- Private
- Safe
- Secure
- Sustainable
- Usable
Naturally occurring work in progress limits
If work is waiting 90% of the time, then only work is ever in progress for 10% of time. Does this impediment to flow create naturally occurring work-in-progress limits?
Work can be waiting for all kinds of reasons. It can be waiting for approval, waiting for someone to become free to pick it up, moving between roles.
Reducing the time work is waiting is one way to reduce the time it takes to get value from that work. But sometimes that isn’t possible, so it’s necessary to work without applied work-in-progress limits.
How we define ‘in progress’ matters. Is work in progress if it has started but isn’t finished? Or is work in progress if it has been started, is actively being worked on, but isn’t finished? In which case, work that isn’t being actively worked on is ‘work in waiting’.
One perspective sees time spent ‘in waiting’ as waste. If that work was finished sooner, then more value would be realised from it.
But, having work ‘in waiting’ creates a natural limit to work-in-progress.
Delivery management and product management: perfect partners
If product management is a science, delivery management is an art.
If product management is about analysis and hypothesis, delivery management is about relationships and harmony.
If product management is about the destination, delivery management is about the journey.
Product and delivery are complementaries, opposites but fitting together to make a strong whole.
What valuable, viable, feasible means in charity product management
Product management attempts to reduce the risks associated with building a solution that isn’t valuable, viable or feasible.
Marty Cagan describes these types of risk:
- value risk – whether customers will buy it or users will choose to use it.
- business viability risk – whether this solution also works for the various aspects of our business.
- feasibility risk – whether our engineers can build what we need with the time, skills and technology we have.
- (Cagan also includes a usability risk – whether users can figure out how to use it, but for simplicity I’m going )
For a charity, these risks show themselves in slightly different ways, but a product still has to be valuable, viable and feasible.
Valuable
The value risk is tackling a problem no one wants solving, or providing solution no one wants to use. To be valuable, the solution has to tackle a non-trivial problem that affects enough people significantly that it’s worth solving.
Viable
The viability risk is tackling a problem that the charity isn’t the right one to be tackling. To be viable, the solution has to fit the organisation strategy, be a legitimate problem for the charity to be tackling, and be fundable.
Feasible
The feasibility risk is of not having the skills, knowledge, technologies, to create the solution. To be feasible, the solution must be within the capabilities of the charity to build and, just as importantly, maintain.
Valuable, viable and feasible
Creating a solution that is valuable, viable and feasible is the challenge of product management in charities, but reducing the risk of not doing so is the value product managers bring to charities.
Charity mission and vision for defining boundaries not goals
I’ve written previously about why I don’t think charities should be working to put themselves out of business.
Maybe we’ve misunderstood mission and vision and that’s where we get the idea from.
If we think of a charity’s mission and vision as a goal to achieve then the logical conclusion might be that once the goal is achieved, there is no longer a need for the charity to continue to exist.
But if we think of mission and vision as setting the boundaries for a charity, defining the area of influence, it’s market space. Now the charity can do any work within in that space. Even if they solve a particular problem, they are free to shift their efforts to a different problem or expand their space and continue to do good in the world.
How new changes get adopted
Rogers’ adoption curve model, a model for understanding how new ideas and practices are adopted, helps us create a realistic approach to bringing about any new change.
How adoption happens
Roger’s adoption curve tells us to expect that for any new change, the number of people adopting that change is different throughout the lifecycle of that change. A few people will adopt change early, more as the change becomes generally accepted and there will be a small number who take longer.
We can take this knowledge and use it to help us make change adoption easier. Rather than think that everyone will accept a new change at the same time, we can identify the early adopters and work with them first to get the change embedded. Once these few have accepted the change, it’s easier to move onto larger groups of people.
For example, suppose we want people across an organisation to change how they manage projects:
- Innovators – Start with a small number of projects managed by people who are confident in using and accepting new ideas and techniques.
- Early adopters – Projects managed by people who have worked with the innovators and have seen the new approach in action.
- Early majority – Projects managed by people who are aware of the projects managed in the new way but haven’t been involved in them, and are proactive in adopting new practices.
- Late majority – Projects managed by people who aren’t aware of the new project management approach but are open to adopting practices.
- Laggards – Projects managed by people who aren’t aware of the new project management approach and are not open to adopting practices.
How to make adopting change easier
With all groups of people, there are things that can make it easier to accept the change. Successful adoption has five key characteristics:
- Compatibility – The more it fits with existing behaviour and tools, the more easily people can make it part of their working process.
- Trialability – The easier it is to try before having to commit to using it, the more people will start using it.
- Relative advantage – If it is better than the alternatives, then people will see the value of using it.
- Observability – The more people see others using, the more they will want to use it.
- Simplicity – The easier it is to learn, the faster it will be adopted.
For any kind of change in an organisation, trying to get everyone to adopt something new at the same time is much harder than using proven knowledge and techniques to bring about change over time.
What user stories are really about
User stories do not have to follow the format, “As a [persona], I [want to], [so that].”
User stories do not have to be used to assign work to developers.
User stories do not have to have “story points” or be used to estimate how long work will take.
User stories are so much more…
A user story is a ‘boundary object’, a conceptual object that has can be interpreted differently by different people but which have enough immutable content to maintain the integrity of what it is communicating. They allow “coordination without consensus”, meaning that not everyone has to agree on how to define and interpret the information the boundary objects holds in order to make use of it how they need to.
The concept of boundary objects was introduced by Susan Leigh Star and James R. Griesemer in a 1989. They describe boundary objects as:
Boundary objects are objects which are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.
User stories are a way for people with different domains of knowledge to share a common understanding in a way that makes sense for their specialised knowledge domain and has . A good user story makes sense to a content designer thinking about content and to a developer thinking about code. The story is talking about one thing only, but different people with different perspective can understand the story in a way that makes sense to them.
Writing good user stories isn’t about following a prescribed format, it is about creating boundary objects that work across domains and give people the knowledge they need.
Lightweight digital governance
About lightweight digital governance
What is lightweight digital governance?
Governance is about collective responsibility.
Lightweight governance assumes competency and sets out to create the best conditions for people to get things right.
Lightweight digital governance is about using modern, agile, digital, ways of thinking and doing to create the best conditions for collective responsibility to flourish.
When those conditions exist, things are improved, how they are improved improves, and those improving them see the improvements.
What’s the difference between lightweight and heavyweight governance?
Heavyweight governance focuses on having decision-making controls and checkpoints separated from those doing the work.
Lightweight governance focuses on ensuring people have all the skills and knowledge they need to make the right decisions about their work.
A lightweight digital governance model
One part of the governance model ensures the thing being governed aligns with strategy, sets the standards, designs the procedures and provides the training.
The other part of the model implements the standards and procedures, does the necessary work, checks it for quality, releases and monitors it to feedback on how well those standards and procedures meet the needs, whether there are gaps in the training, and new things need to be governed.
The model is:
- Cyclical – the cycle can be monthly, quarterly, annually, etc., depending on the needs of what is being governed, but it relies on a feedback loop for its success. This helps the governance to improve as it improves what is being governed.
- Separates activities – but doesn’t separate the people or their responsibilities. Those involved in implementing a standard can be involved in using it and providing feedback to improve it.
An example
Governing a charity’s website.
Those involved decide that in order to govern the website effectively that need to take collective responsibility for accessibility, branding, performance, security.
A traditional heavyweight governance model might make different teams responsible for each of those things, but lightweight governance recognises that creates a coordination burden that leads to more trouble than it’s worth, so it’s better that one team with all the skills it needs take on that responsibility.
The team sets the standards for the website, e.g., WCAG 2.1 for accessibility, password length for security, and they write the procedures for checking readability scores or vulnerability testing, and they create training in how to use the procedures to achieve the standards.
They then create content on the website, develop new functionality, etc., applying what they learned in the training, and feeding-back on how that’s working so it can be improved.
The more quickly things move through the cycle, the more quickly they are improved, so critical changes should move quickly and less important change can move slowly.
Why charities shouldn’t be user-centred
First, what is user-centred design?
User-centered design (UCD) is a collection of processes that focus on putting users at the center of product design and development.
Ekaterina Novoseltseva
Over the past few years, more charities have been adopting user-centred design practices when building a new website, redesigning grant making processes, and creating new products and services. It’s good progress away from creating these things based on what the organisation thinks is important or the opinions of senior people, but it isn’t without its problems.
UCD is always constrained by its purpose of meeting the needs of individuals. But by focusing on the needs of individuals charities can inadvertently reinforce the continued existence of those needs. UCD has it’s place in meeting immediate needs, but it doesn’t create long-term change. It isn’t equipped to move beyond identifying and responding to the needs of individuals and into the systems that create those needs.
System-shifting design, with its emerging practices and approaches that focus on how systems can be redesigned, offers charities a different way to think about how best to help people. SSD often works in an attempt to remove the problems that people face rather than just making it slightly easier for people to deal with the problems.
System-shifting design is very new, and I don’t know of any charities using it, but if a charity has a mission or ambition to create change then it’s likely to be a more successful design methodology than UCD.
Strategy as a decision-making tool
A strategy is:
a plan of action designed to achieve a long-term or overall aim
I disagree. I think that’s an outdated view of what a strategy is.
In the volatile, uncertain, complex and ambiguous modern world, strategy should serve more as a decision-making tool for facing situations that weren’t predictable when the strategy was created. Any strategy that serves only as a plan of action, a to do list, is limited to what was known at the time.