Using lean prioritisation to create a shared understanding and rapid decision making
By Steve Cottle
As the 2019 hackathon rally cries intensified from the Labs team at FT HQ, I decided to add my name to the list. It would be my first hackathon at the FT and instead of forming my own team I decided to let the organisers drop me into a team of their choice.
On the day I had two teammates, a Security Engineer and an Engineer, it would be their first hackathon, too.
Having overlooked the schedule before the start of the two-day event, what instantly struck me was how little time we’d have to build a thing. The introduction didn’t start until 10am on Thursday and the presentation and demo of our built thing was due by 2pm on Friday. Taking a look at the microsite in more detail to see what I’d let myself in for, there was a particular tip which stood out:
- You do have to build something non trivial, that works, during the hackathon. “Coulda/Woulda/Shoulda and here’s a slide deck of what we wished we had been able to build” is not acceptable.
So the thing had to work and in a window of only 4 minutes we had to sell it to a panel of judges. Judging categories included:
- Best in Show: Most personally relevant FT
- Most group relevant (can we tailor to a group level?)
- Most doable / immediately impactful (all the pieces exist, JFDI)
- Newest, Least Comfortable for the FT, but… (you know what, this might be a thing)
- Most enabling (our thingy makes all the things possible)
- People’s Choice (who won over the room?)
- Bonus prize: Most Creepiest
With the intro over we had to get cracking, but where to start?
Killing ideas quickly
In order to achieve a working thing in the time we had, we needed to keep our approach lean, stay focussed, have a shared understanding of what decisions we were making and why we were making them. If we weren’t all aligned we may not have been fully invested in our idea which would risk the thing not being built.
We started with the goal — Create a more personally relevant FT. More relevant for who? We thought of some FT users which may have different needs or challenges for us to address and chose a younger audience to focus on.
We used the jobs, pains, gains framework developed by Alexander Osterwalder at Strategyzer. Identifying possible jobs (outcomes / jobs our user wants to achieve), pains (bad outcomes, risks, obstacles) and gains (outcomes which would make our user happy) relevant to our user.
We then put forward ideas to provide pain relievers, gain creators or products or services to get jobs done. Each idea was as valid as another as we quickly discussed each. We didn’t go into details here, we gave brief overviews of our idea and moved onto the next, we’d figure out the details later on.
We prioritised our ideas by using a prioritisation matrix. This matrix is simple, collaborative and perfect for ranking ideas or features in order to see their relative value against two criteria. We often use these when trying to work out what to build next by assessing user value against effort. If an idea has high value and low effort then this is what we do or build first. For this exercise we used the following:
- Customer value — high / low
- Could we build it in time? Yes / no
Part of the judging criteria was an ‘Oh god, no’ award which we added to a post-it in case one of our ideas was suitable … which we didn’t believe any were, so this was left unused.
We decided to choose an idea which was high customer value vs mid-low chance of being built — a way of pushing articles/ daily summaries (based on user settings within ft.com) to a user’s Instagram or Snapchat feed.
After discussing the details of how it could work and performing some initial research we decided that it would be difficult to implement. Initial thinking was that we’d need to create separate Insta/ snap accounts for each user which may be against their respective terms of use, and also FT already push content via various channels so we felt we were copying an existing idea. We killed the idea and moved on.
One user journey of the Instagram / snapchat idea ^. We killed this idea and moved to the next.
The next well-ranked idea was to unlock the paywall for 13–17 year olds, but as a team we seemed to be hesitant in taking it forward. We decided to individually rank the top 3 ideas on the matrix and unlock the paywall for 13–17 year olds came out with the most points. We still seemed hesitant so we mapped our final three ideas to a new matrix. This time the axis were:
- Chance of winning
- Could we build it in time?
We believed that unlocking the paywall for 13–17 year olds had the most likelihood of being built and a mid-high chance of winning.
We committed to this and got cracking.
If you’ve ever been in a meeting with a group of colleagues and someone says, “so what do we think we should about X?” For whatever reason, not everyone wants to give an idea, and of those who do give an idea there’s usually an arbitrary way of deciding which idea is actioned (it’s usually the idea which is liked the most by a more vocal member of the meeting). By individually thinking of ideas, writing them down, giving each one equal value, evaluating each idea against the other, everyone in the team is a part of the decision making journey.
User journey
We thought we could use AI to analyse the age of the user trying to access an article. While my teammates researched the tech, I started looking at the user journey.
After showing the team and incorporating some feedback we were all onboard with an initial pass of the journey. As the tech was becoming more defined and the build was underway, I put some screens together to see how the journey could look in the UI.
This was then put into InVision prototyping software to sense check.
The tech
JavaScript code is injected into the live version of ft.com locally in the browser using our custom made Google Chrome extension.
Clicking the injected button on the site triggers the default webcam to take a photo and send it to our service hosted in AWS. The service returns the estimated age of the person and then the user is allowed through if that age is under 18.
The service in AWS consists mainly of:
- AWS S3 bucket used to temporarily store the photos
- AWS lambda which in turn uses the photo from S3 and AWS Rekognition service to run facial analysis on the photo. The Rekognition service returns an estimated age range of the detected face to the lambda. The lambda computes the average from the lower and upper ends of the range, for example the range ‘18–22’ is computed as (18+22)/2 = 20 so the returned value is just 20. The lambda returns the final estimated age.
The result
The resulting app allowed a user access to all FT content if they looked under 18, enabling younger (looking) readers to learn new skills and topics with no investment of time or money.
We knew from the outset that the idea wouldn’t be implemented, though it was a fun way to solve a pain point for our users and experiment with new tech. The journey to the end result was as important as producing the final experiment itself. The judges naturally had their concerns, there was a clear issue with taking photos of users under 18 to grant access to a product. Another flaw was that in lieu of having a teenager to help us demo the app, we printed onto paper the face of a younger looking person to unlock the paywall. “Does this not show a problem with the system?” one judge commented. Yes, yes it does.
When your team is given a goal it’s important that they work together on their experiments from the outset of the journey. They become more invested, aligned and have a greater sense of ownership — their voice has been considered as much as anyone else’s.
After a day-and-a-bit we had a prototype which we could have taken to users to generate feedback, to further decide whether to kill, pivot or persevere. The great thing for the team was that we all knew where the idea had come from and why we had chosen it.
