Find a Player

In Autumn 2018 I had the idea to create an app that would help people fill in missing numbers in their sports fixtures. As a regular member of a small sided cricket team and casual five aside player, I was well aware of the pain and anguish involved in running casual sports teams.

The next day I googled to see if anyone was working on this problem and as it happened there was a small start-up in Glasgow running the Find a Player app. I reached out to them and after an exciting chat they asked if I wanted to join the team.

With a professional background in creative advertising and experience moderating focus groups, I got started with a few user research sessions.

I recruited non-users for the first round of user research.

I sat with them asking what sports they played, how they currently organised them and what their biggest pains were with their usual process.

I then introduced the product. I'd observe them signing up, record their initial impressions and what they thought about the idea and execution of the app.

What was clear from this set of interviews was that the idea was liked and everyone could see how it might be useful - but the existing app felt dated and not user-friendly.

Alongside that there was some confusion as to what the app really was.

Was it like eBay for sports people? Matching players to organisers, as the name would suggest.

Or was it more like what Hello Fresh does for home cooking? A transformative way to help organisers run their game.

Or was it something bigger than that? More like a social network of sports people.

What was clear was that it wasn't totally clear for prospective users.

These interviews also highlighted some standard usability problems across the app. Below I'll share some of the work I did on event creation, onboarding as well as creating a design system.

There were a few stages that users were confused, audibly sighed or were irritated while going through key flows.

It was clear that a few general UX principles needed to be applied across the app to iron out these pain points.

In some screens the app was using over 40 different colours. Colourful UI's are not an issue when used deliberately. But when applied inconsistently, the feel of the app becomes jarring and hard to navigate.

I simplified the colour scheme down to 9 colours that users would learn to associate with various states - positive actions were predominantly green, warning states were red etc. And the two blacks and greys accounted for designing in dark mode.

This is principally an ergonomic design decision, but one that's often overlooked.

Simply, most people hold their phone with their right hand. And since 2013 smart phones have been getting bigger, which means buttons at the top of the screen are harder to reach than buttons near the bottom of the screen.

So when designing every screen it was important to mark out what the primary, secondary and tertiary actions were - to ensure the primary action (most likely/desirable) was close to the right thumb.

It's really amazing how tiny, simple changes like this keep a user in flow and relaxed when using the product.

"Clarity refers to the focus on one particular message or goal at a time, rather than attempting to accomplish too much at once" said the interaction designer, Michael Hoffman.

There was a general trend in the existing app to try and reduce the total number of screens the user has to go through in any flow. While this looks like an efficient UX on a wireframe, it tends to result in a bad user experience.

Generally, going through 100 clear screens is better than going through one cluttered one.

When users see one task ahead of them, it feels manageable and they won't have to think.

When users see they're going to be asked 40 different things they'll often sigh, get annoyed and leave the process before they start, because they "CBA right now".

I put an emphasis on clearing up screens by removing anything that wasn't absolutely necessary and reducing reliance on explanatory text.

They say first impressions last the longest so it's important to consider the first encounter users have with a product.

To start the process of improving the app's onboarding I plotted out an experience map based on interviews I'd done with existing and prospective users.

The experience map helped us identify the different stages that prospective organisers were most likely to discover the product was during "panic recruiting".

This meant the organiser was in a state of high anxiety because their game was at risk of being called off if they couldn't "find a player".

This anxiety state meant the user was highly motivated to get through registration but their tolerance for unnecessary friction was low - i.e. small UX problems made them angry.

The registration interviews on new users revealed some positives as well as pain points.

From these findings we wire-framed a new flow that you can see in blue below.

Once the above prototype was built and live, it was up to me to do a few more rounds of user research to iron out the "last mile of UX". These would help me identify where anyone got stuck and any potential error states or edge cases.

What was great about doing research for onboarding and registration is you can go up to anyone at the side of a sports pitch and get them to run through it. Once I was confident the flow took two minutes or less it's hard for people to refuse!

Another crucial flow to get right in the app was the event creation - the process organisers would have to go through to set up a game on the app.

In research I found that new users were taking three to five minutes to set up a game, and there were many bumps in the process.

There's a lot of upfront information to capture from the user when they want to list a game on the app but having watched users struggle thorough the existing flow I felt it needed to take less than two minutes.

During user interviews I'd get organisers to tell me how they ask someone to join their game if they saw them in person - and I'd get them to say it out loud.

A typical response went something like:

"Hey mate I've got a game of footie on Thursday in Streatham if you want to play? It's just a group of work mates and we're one short. Nothing too serious."

‍What struck me when reviewing some of the interview transcripts was it was very common for the order in which they'd ask would be the same: Sport type, Time/date, location, who's playing and then any extra details.

So when drawing out a new set of wireframes it seemed sensible to start by borrowing the language flow of what users were saying.

Once the new flow was designed and live it was easy to analyse the performance to see where users were getting stuck or taking time.

The redesign took the time to create an event down from 3-5 minutes to an average 1.8 - 2.5 minutes per event created.

But that wasn't the main improvement, the new flow had a 4x effect on the conversion rate of events created.

So while the previous flow only 10-15% of those who started creating an event would finish, this new UX delivered between 40-60% week on week.

Those are just three examples of the UX/UI work I did at Find a Player. While I was there we also launched payments, and re-skinned the app according to the simplified design system.

One final design responsibility I had was briefing an illustrator to visually bring the benefits of using the find a player app to life.

Finding players, collecting game payments and helping players find games across a range of sports.

If you're familiar with the start-up world you might have read the essay Start Up = Growth, by the inimitable Paul Graham.

In it he says what makes a start-up distinct from a small business is a start-up's scalability.

He shares some examples of iconic start ups and how obsessively they cared about growth.

When I joined Find a Player there was some metrics being discussed and measured but it was unclear whether they were the key metrics nor was there a regular forum to review them.

I felt it was important to set up a regular metrics review to ensure the whole team was orientated around moving the metrics that mattered.

A popular framework that many use is the pirate metrics funnel.

The first task was to work out what these pirate metrics meant in relation to the Find a Player product. We had to prioritise which were worth tracking, as analysis paralysis is a serious issue to getting things done.

Once we'd prioritised, we would work out how often to review them and set goals in order to improve them.

As a pre-PMF start up we agreed to focus  the lower half of the funnel; Retention, Revenue and Referral.

We used Facebook Developer Analytics to track these metrics. (Which is a painfully slow and hard to use tool - I'm sure there are better analytics tools out there).

We reviewed them weekly in a metrics review on a Friday morning where the whole team would discuss, in depth, what had happened to the metrics, why they might have moved, what's changed in the product this week and set targets for we'd like to be next week.

I chaired this meeting for 27 consecutive weeks and shared the metrics pack for everyone in the team - to align everyone in the company around working on what mattered.

I can't share precise metrics as I am no longer at Find a Player but I can show a graph of product usage during the first half of 2020. Bonus points for you if you can guess what happened around the middle of March.

While quantitative growth metrics were really important with regards to measuring progress of the app - they were not sufficient to tell us how improve the product.

However, having no regular review of quantitative metrics would mean you don't know if your product is going in the right direction.

Over the course of my time at Find a Player I was proud to have set up, in combination with the head of engineering, a comprehensive metrics tracking system which would put the team in good stead to be able to provide accurate, hard evidence of product improvements to potential investors and new-team members.

Product Management can be a tough job to explain. Sachin Rekhi's post The Top 10 Deliverables of Product Managers sheds the most clarity on what a PM has to juggle.

He breaks it down into Vision, Strategy, Design and Execution.

As Find a Player was still a small start up, we didn't have any one individual assigned as a "product manager", so most of the team had to chip in to take responsibility for different parts of the vision, strategy, design and execution.

Below, I'll outline what I felt I contributed to product management at Find a Player, but it's important to stress it was always a team effort.

The vision of the company usually comes from the CEO. And the clearer the vision, the easier it is to aim for.

Find a Player's vision revolved around making it possible to play your favourite sport, anywhere in the world, through the touch of a button.

The mission was to build the most seamless way to play sport, as easy as ordering a Deliveroo, or buying a gig ticket on Dice.

Strategy at a start-up is typically a conversation about product market fit.

We had to identify where we were in relation to PMF, and how we were going to get there.

Product-market fit is a tricky thing to describe to anyone who's not familiar with the term - but in essence its the part of building a product when you realise you've built something that people really want.

It's famously hard to measure, they say you can always feel when it's not happening.

Andrew Chen, ex-head of growth at Uber, says about product market fit:

This quote certainly struck a chord with the team. We knew we had an idea people wanted but we hadn't built what they wanted yet.

Thankfully, Rahul Vohra at Superhuman had shared a guide he'd created to measure progress towards PMF and how that helped his team to focus.

In short, his PMF engine asks 4 questions.

The aim of the first question is to reach 40 plus percent of respondents saying they would be very disappointed if they could no longer use the app.

The aim of the second question is to identify the users who say "people like me".

The third question teases out the strengths of your existing product.

The fourth question highlights what you need to improve the product.

He then recommends spending 50% of your time continuing to improve your strong points that user's highlight in question three. And then spend the other half of your time working on the areas that are highlighted in question four.

I ran the PMF survey on existing users and it gave us some clear feedback.

This process gave us a quant metric of how close we were to PMF.

It also gave us a clear hypothesis for how we could get there.

In short, we needed to continue to improve the whole experience for game organisers; not necessarily just for finding players and finding games.

In addition, we should remove any inactive users or games, and work hard to maintain an active user base.

For the next 12 months we had to evaluate any new ideas for product improvements against this hypothesis.

While the vision and mission of the company were fairly clear - we needed to break down the steps towards realising that vision.

As a seed stage company, it was felt we needed to demonstrate clearly that we were making progress towards product-market fit and building a business with a tangible revenue stream.

This meant prioritising working on parts of the product that would deliver a revenue stream as well as improving the user experience.

We worked out we needed to launch the group payments feature and demonstrate its impact on the PMF score, before looking to do anymore fundraising.

We set a date on when we expected to start the process of raising money (pre-Series A) and worked backwards from that date to determine what we needed to do week-on-week.

The challenge of deciding what to work on when you have limited resources is a universal one.

I learnt the hard way that it's very easy to spend weeks designing and shipping something that ultimately has little impact on the most important metrics.

On top of that, we were having lots of ideas about what would be nice to have in the product, spending long meetings discussing these amazing ideas (they're always amazing), and then letting them sit in the product backlog waiting for them to get built.

As our head of engineering rightly said at the time "this is the opposite of agile".

This was a relatively useful process - however, what would inevitably emerge was tens of ideas what would sit in the backlog for weeks or months, which would either become stale or would need re-prioritising again at a later date.

Instead of wasting lots of time discussing these old ideas again and again, what I felt we needed was a more formal process to shape the ideas before they were pitched, discussed and estimated.

Ideally new ideas would arrive better shaped, formed and tested - so we could make more accurate predictions as to their likely value.

I looked around to find some examples of how other companies were solving this problem. One insightful document came from Hiten Shah who had studied various product teams' working habits at companies like Amazon. This Product Habits document informed my approach.

The loop starts with Research.

Research typically involves listening to users; existing or potential. When listening to users we would ensure we used principles of the Mom Test, so that we weren't asking leading questions or taking compliments as reliable feedback.

Problem Definition.

99.9% of the time, ideas that were presented, built or designed without a clear problem statement would create more and more work, eventually demoralising the team.

Working to write down a clear problem statement using a technique like Jobs-to-be-done "People don't want to buy a quarter-inch drill. They want a quarter-inch hole!" or the Kaizan 5 Why's were very useful in reframing problems and identifying root causes.

Brainstorm.

Once you have defined a problem, it's a lot easier to come up with lots of different ideas that might solve it. This contrasts with when you already have an idea, and you love the idea and can't seem let go of the idea. Having an attachment to one idea stops other, sometimes better, ideas rising to the surface.

Create.

This is the exercise of bringing to life the the best ideas from your brainstorm. Taking them from a raw form into something more tangible.

If it's a new illustration style, mock up the first attempt at it.

If it's a new feature idea, write it up as if you're writing the feature announcement email.

Prototype/Test.

Show the idea to other people. Ideally users.

Any form of prototype is good and it's better if its rough.

For example, if you've already written the feature launch e-mail, send it to 50 users, see how many reply showing an interest.

If your idea is that the app needs speeding up, first try slowing it down to see if users complain.

If you think users want a specific setting in the app, put a placebo button in and see if users click on it.

Do what you need to do to make sure you're not misleading users. But also do what you need to work out if your idea is worth building, shipping or scaling.

Learn and share.

Write up your findings from your prototype test. Even if they were negative. Especially if they were negative.

Write these notes down so other people can review and learn from them - this will help them give you some ideas to go back and test again.

Build

Once you've shared the idea with the team. Work out what the minimum-viable version of this feature you could launch and set a deadline for when it will be launched.

Once it's out, go through the cycle again.

While this more formal cycle looks longer than the more informal cycle I shared upfront, it reduced the likelihood of work getting out of control or wasting weeks on a feature that flops.

In the three months before working through this cycle we managed to push out two product updates in the space of twelve weeks.

Once we started implementing this approach, we were releasing updates every week over a similar time-frame.

Now this cycle is far from perfect and 'number of releases' is not an entirely reliable gauge of progress - but both the engineering team and users remarked on how the new tempo improved their respective flows.

I loved my time at Find a Player, I got stuck in doing things that don't scale, shipping product and working closely with developers.

It taught me that to getting to product-market fit is a process of focus and iterations - the faster you can make that loop the more likely you are to succeed.

If you're in the process of trying to build a marketplace or similar network, and have any questions, I'd be more than happy to hear them.

Thanks for reading.

Go well.