But there’s one aspect that’s often overlooked and that’s the inherent racism of the RFU’s adopted anthem. The story goes like this. The RFU finally picked a black player (Chris Oti) – the first black player in around 80 years. He scored, at which point various sections of the crowd started singing a traditional black sing harking back to the days of slavery – indeed, according to this account, believed to be written by a slave couple.
There is a BBC account that has interviews with several of the people who were each solely responsible for starting the song. One has to ask if so many people started the song, why they each only chose to do so in the game where Oti was picked.
It is of course quite possible that the fans were unaware of the song’s origins. But times have changed since 1988 (for the rest of the country it was earlier, but some groups take longer to catch up). Casual racism and misogyny are rightly less tolerated now; we cringe at the television shows of the day and the stereotypes we’ve moved on from. The antics of Gene Hunt and his ilk are banished to a bygone era and the amusement gained is at the belief that such behaviour would be acceptable.
When younger, I simply thought the confederate flag was the decoration on top of an orange car that went round corners sideways. To me at six, the flag was associated with driving away from police officers while keeping a car airborn. Obviously as a grown up, I’m aware of the awful past and what that flag meant.
Swing Low might not be a flag used in pursuit of oppression. But at best the singing of a song about slavery in commemoration of a black player scoring is extremely inappropriate and somewhat Alf Garnett. It is time for the RFU and its fans to move on.
In recent years, product management has expanded from focussing on “building it right” – ensuring that a backlog is delivered to an acceptable cadence and quality – to “building the right thing”. This means moving away from the illusion of certainty to embracing experimentation.
Coupled with experimentation is an acknowledgement that a product manager is probably not the most qualified person to design the interface or do detailed data mining. More and more, product management teams are being formed of User Researchers, Data Analysts, UX and UI designers as well as Product Managers. The goal of this team is to identify user needs and create services that meet those needs whilst driving business value.
The diagram below shows how this system can work. We begin with insights, identify user needs for a given target group that will drive business value and hypothesise concepts that will satisfy these requirements. These hypotheses are necessarily experiments: we might be right, we might not. We only find out by creating something (or better, things) and testing.
Following this product discovery process we create artefacts that aid communication and understanding: user stories; prototypes; acceptance criteria.
And after some validation, we are ready to build – which is where familiar tools such as JIRA or Rally are used.
Coordinating the elements of Product Discovery can be difficult. I’ve known teams attempt to create a Todo / Doing Done board within JIRA; however, the issue is that there is no single task that moves.
When a development team works on a story, the story card remains constant and moves into different stations (e.g. Analysis, Design, Build, Test, Deploy for the classic Scrum-as-Waterfall model).
However, in product management, we identify Insights that help us identify one or more user need. Concepts answer these needs – ideally more than one concept as we should be testing. And a Concept may meet more than one need.
Each concept will give rise to one or more user stories and one or more designs.
So there’s an issue with what we are tracking – we tend to think of stories but are actually tracking the meeting of needs. And even these may be met by more than one concept, so there isn’t a neat 1:1 mapping from one phase of discovery to the next.
From what I’ve seen of many tools, the collaborative product management approach is supported by “Hey colleagues, send me your ideas and we’ll vote on them!”. While it’s great to gain ideas from the wider company, these are actually only insights, from which we must still identify user needs. I also have my reservations about voting. Ultimately we want to drive business metrics, not popularity.
Observed Problems that need resolving
There are several issues that I’d like a tool to resolve:
a lack of a central storage space means that team stores insights separately. This causes research to be repeated and learning is not shared across teams
a lack of tracking means that we cannot easily trace development requirements back to the originating insight. At best this leaves teams open to HIPPO prioritisation; at worst it means that the stories for a development team might not answer the original need
No common storage or version control causes teams to fake this on Google drive (or similar) or on local storage. The main issue with Google drive is that people forget to remove staff who’ve left; it’s an administration headache.
No natural coordination between work in progress and product roadmaps. Sure, we don’t want roadmaps going forward for years. But we ought to be able to identify themes and track the progress of concepts that we believe meet the needs within those themes.
Tracking associated non-development tasks (e.g. creating a case study, training customer support) gets tracked in yet another place, such as Trello. Again, Trello is a great tool but it’s not integrated with this process.
What I’d like to see
Easy storage of user insights
Traceable progress from insight through to development backlog (and maybe even MVT…)
Building of roadmaps
Easy and ready sharing of concepts / prototypes, etc
To conclude, I’d love a tool that does this or that can be readily adapted. Should I find one, I’ll be sure to publish my experience with it. So please leave your thoughts below.
Tool vendors, I’d love you to join in! Feel free to add comments about how your tools fit with these needs.
Appendix: User Stories for Product Discovery
As a User Researcher, I want to log and share insights and research, so that effort is not duplicated and learning is not lost.
As a User Researcher, I want to easily retrieve stored insights from across the business, so that I can start to identify related user needs.
So we need a big data store that swiftly searchable and trivial to add to. It’s essential that we can tag and log basic information. It’d also be useful to have easy addition by, say, email.
And we need to be able to swiftly pull back these insights. See the age of them, who logged them, etc.
As a User Researcher, I want to distill insights into needs, so that I can identify what our user truly wants.
As a User Researcher, I want to tag which insights have been pulled into user needs, so that we can later identify which insight sources are most effective or which insights are most helpful
OK, so we might not use the tool to *derive* user needs – this could be a group exercise done on a whiteboard. But when we’ve detailed them we need some means to track them for analysis and so that we can see where our user needs come from.
Concepts & Hypothesis
As a member of a Product Management team, I want to pull user insights, data insights and KPIs into a coherent hypothesis, so that we can build better concepts and tests.
As a member of a Product Management team, I want to track where my concepts come from, so that we understand the user need we are building for and the outcome we believe that we’ll see.
Again, this might not be *done* within the tool. But we need to be able to track the activity: where things come from and what we’re doing. And attach the concepts / reference where they’re stored.
As a Product Manager, I want to be able to trace back to concepts, needs and insights when writing stories, so that my dev team and I are reassured that we are adding value and meeting needs.
As a UI designer, I want to be able to trace back to concepts, needs and insights when creating designs and prototypes, so that I am reassured that I am meeting the correct user needs.
As a Product Manager, I want to create Roadmaps based on opportunity, so that the team can work toward these strategic goals
As a Product Manager, I want to track associated tasks so that I can deliver a complete product and track progress toward that goal
The Kingston Cycling Campaign has patiently dealt with each of their objections and you can read this over here.
Objections to the Route
So what are the New Malden NIMBYs scared of?
Firstly, there’s the description of the route as “lycra alley”. Frankly I doubt bike races will be held here, so this description is somewhat of an exaggeration. At present, cyclists are compelled to keep up with traffic for safety, hence wearing lycra and riding road bikes in town. This sort of project will work to reducing that need by separating differing modes of transport.
Right, so a bike race isn’t going to happen. What of the concern with fly-tipping, in particular used syringes? Firstly, let’s be clear. Lance Armstrong is no longer involved in cycling. More seriously, there’s already a footpath there. Will cycling encourage unwanted behaviour in a manner that walking (or staggering) doesn’t? And why assert that it’s clinical waste that will be dumped? Perhaps they’ve seen cargo bikes and hypothesised just how much litter these could carry.
What else? Ah yes, terror threats. Apparently creating a cycle route here will encourage terrorism. This is because terrorists are known to be unable to use footpaths, instead insisting on riding or driving everywhere. It’s widely stated that cyclists are undesirable types, so perhaps this concern is well-founded.
What this route will actually do
Let’s face it, these arguments are nonsense and detract from the genuine and fixable concerns of light pollution and home security.
This is not a route to solely benefit the hardened few who already cycle. It’s something for all those who want to cycle but feel unable because of the lack of cycling facilities.
Mark Wagenbuur’s channel has some great examples of Dutch infrastructure. Take a look and see whether the people who use everyday safe infrastructure are worth getting so worked up over. This is what is being proposed for New Malden. It’s quiet, safe and utterly mundane in the Netherlands.
Click here to add your support to the scheme and add to the voices calling for inclusive towns that are accessible to all.