How I built the right thing for the wrong people and what I’ve learned
— Product Development, Lessons Learned — 6 min read
At the start of January 2021, JiffyCV -the app I’d spent about 7 months working on- hit the app stores.
This was the first app that I had created based on an idea I had and during the ideation and development stages I thought I was doing enough to get feedback on the idea and the app as it grew.
Before starting the app I surveyed people about what their biggest pain points were around using CVs to apply for jobs. I found a number of solutions to these problems and how this could scale out to multiple business models.
In order to start the journey towards these larger business models I decided to tackle one of the problems — maintaining multiple CVs — and built an app to do this.
The rationale to do this as an app was that it’s a one off cost, and as the data is stored on the user’s local device I’m not exposing myself to risk around data storage. I’m self-funding this app and building it as a side project so keeping costs and legal risks as low as possible is a must.
Building JiffyCV
I started by building prototypes and ran user testing sessions to iron out potential UX issues with the UI, I spent hours on calls with people that I knew who could give me insight into the different problems I might encounter in the domain I was working in.
During development I was demoing functionality in order to make sure that what I had produced was meeting the needs of the people I’d spoke to and as we went into beta I was jumping on calls to gather further feedback.
The beta went well, in the end there were around 30 people signed up and aside from some bugs at the start, the feedback I was receiving was that the app was good.
I thought I had built something that solved a problem people faced and would then be the cornerstone for a roadmap that would see all kinds of awesome integrations and change the job hunting process for the better.
The app launched and three weeks later the downloads are still below 25 across both iOS and Android, but I’m not surprised because as much as I thought I knew about validated learning I’d missed an important consideration.
I wasn’t talking to those who would actually be using my app.
I was talking to people working in a wide range of industries in order to create a data model that would work for every scenario imaginable but I wasn’t actually validating the idea with people who were proactively looking for work and needed to generate a number of CVs to use in their job hunt.
It might have been my lack of experience working in a product owner role or my inner developer wanting to build the perfect model for the data the app would be using but ultimately I missed the point, and I missed it massively.
Realising my initial mistakes
Just after the launch of the app I finished reading The Lean Startup, and the book was instrumental in helping me realise the mistakes I had made.
If you’ve not read The Lean Startup yet and you work in a team that is building some form of product or service that has an end user I highly recommend you buy a copy.
I was naive when I started JiffyCV. I viewed the need to collect analytics on how apps are used as invasive and something that was nowhere near relevant to anything I built, but I’ve now come to realise that these tools are a necessary evil.
When I ran the beta for JiffyCV I was relying purely on feedback from people who’d signed up for the beta, that is people who I mostly knew either through my personal or professional network.
I had no means of actually seeing if those taking part in the beta were actually exhibiting the types of behaviour that I’d have hoped my app would assist with.
This meant that I had no concrete evidence of the value that the app was providing to users and instead the metrics I was using to determine if the app was meeting user needs was bugs and feedback from people who may have not even done the things in the app I was looking to validate.
Shortly after launch I retro-fitted analytics into the app in order to collect this information and with that data available started to see that the functionality I had spent ages trying to design the perfect solution for wasn’t being used at all. Granted the user base I have is so small that it’s hard to really claim that the hypothesis has been been proven wrong but it’s certainly not a good sign.
Realising I was about to make more mistakes
With the knowledge of how the users are using the app I started to think about what I could do to improve the UX to get more people to use that functionality.
I invested a lot of time refactoring code so I could make changes to the code base quicker and I spent time trying to think of new ways to make it easier for the user to work with the functionality.
I eventually decided to take some time away from the app in order to prevent myself from burning out, but also to reflect, and I came to the realisation that I was ultimately doubling down on what could very well end up being a bad idea.
Instead of trying to improve something which may never have any use I should have been using that time to explore other ideas in order to learn more about what customers actually value and business models that those ideas may unlock.
Additionally, I’ve come to realise that while the idea to build an app had the benefit of not exposing myself to the risks of storing user data and finding myself having to pay extortionate server bills if the idea took off I also locked myself into a pretty long development time which meant that I didn’t get to realise some of the mistakes I had made until way later than I would have if I had built a website for instance.
What I’ve learned from my mistakes
There’s been a number of things I’ve learned from taking the time to take a step back and reflect on the way things were headed. I think they fall into two camps; product development and personality traits.
On the product development side I’ve learned:
- It’s important to spend time defining your target customer so you can build a group of potential customers before you start development
- Before, during and after development it’s key that you keep engaged with this group of potential customers so you keep on-course
- On a similar note, if people are interested in what you’re doing and you ask them for feedback it’s worth evaluating if they are in your target customer group or not and use this to weigh the feedback so it doesn’t impact your plans
- Do the minimum you need to prove something, if you have a hypothesis you want to test and it requires you to build an entire app with multiple features just to get results then it’s too big
- Use analytics and have a clear, defined set of behaviours you want to track, these will be invaluable for running experiments
- Take breaks, if you’re wearing multiple hats in a project then it’s important to not let yourself burn out as you’ll start to narrow your thinking to just delivering on the plan and not be able to see that the plan might be wrong
On the personality traits side I’ve learned:
- As much as I like to think of myself as a ‘big picture thinker’ I’m still susceptible to not seeing the forest for the trees if something catches my interest
- Reading is really important, especially as I move into product development. I really need to read more books in that space instead of assuming that there’s overlap with the more development focused books I tend to read
- I’m an external thinker and in order to learn new things I need to bounce ideas off others and demonstrate mentorship. Finding a community to do this is key if I’m going to build a better understanding of product development
- While I’m very objective about most things in life I need to stop being subjective about business development practises and look to understand why they work instead of dismissing them based on opinions I hold
Next steps
Now that I’ve experienced sinking hours into trying to fix something that might ultimately be wrong I’ll be looking to go back to the drawing board and trying to build MVPs for other ideas in the problem area.
I’ll also be looking to create a group of target customers that I can work with while I build these MVPs in order to make sure the right thing is being built.
I’m hoping having the right people to get feedback from and cutting down the time required to get an experiment live is going to help correct the course of JiffyCV.