In today's Workshop Wednesday Bolaji (Proton) takes us through the steps to take when solving a problem using tech. These are the steps he used while building Annie, a mobile platform created to ease the pain of music sharing for music streamers.
Check out Annie: https://anniemusic.app/. Make sure to leave any feedback you have on it here.
You can get the recorded session on Youtube (embedded below)
Stay till the end of the recording to learn from the Q&A segment.
Questions asked:
- I always wonder what goes into making the decision on which platform to start building for. For example, why did you guys decide to go with Apple first?
- Have you monetized this? If so, how? If not, what's the plan?
- How do you judge if the problem affects enough people to make it worth solving?
- How long did it take you, from the ideation stage to actual implementation?
- Do you have a specific framework that you use to ensure you adequately understand a problem?
- Curious about the mental toll creating this app has taken.. you mentioned something on not having the confidence ... if you don't mind could you share more?
- Is there a simple software architecture plan you had before making the MVP and or the proof of concept?
- How often do you perform status checks of the problem to ensure you're still "on track"?
- What was the cost of creating the app?
- What is the current usage like? and what is the feedback from your current users?
- What were key lessons you learned building this product in terms of keeping the product on track, considering that the product was mostly built as a side project?
Building a software solution
It's commonplace to find people coming up with solutions to abstract problems OR problems that do not exist. While building software you want to identify a problem - the best way to do this is to ask yourself what is a pain point you have, and sure enough, most times, if it's something you are facing a lot more people are also struggling with it too. After identifying the problem, you want to flesh it out, this helps you understand the problem wholly and will be instrumental while building a solution to it.
Bolaji gives us an apt example:
Say you identify that your AirPods battery drains too fast and are hell bound to come up with a solution for this. 💡 You quickly come up with a fix, let's just hook these up to a car battery, and now the charge on my AirPods last way longer. If you had taken a beat and sat with the problem, you might have noted the reason people use AirPods, is that they are lightweight and easy to port. Your solution, in this case, solves one problem but introduces another / completely negates the initial use case of the AirPods.
You can see why understanding the problem and the problem space plays a big part in the solution you end up with. The better knowledge you have, the more likely your solution will serve the needs of your users.
Some example questions you want to ask yourself in order to fully understand the problem are;
- What kind of battery does the AirPods use currently?
- What are the other kinds of batteries out there?
- What is stopping Apple/manufacturers from using the alternatives?
Check for existing solutions / current workaround
Since this is a problem that people face, there must be a workaround and/or existing solutions to the problem.
Take Annie for example, to share a song one is listening to you might find people taking a screenshot of the song on their streaming app and sharing the image, or one might have to actually type out the song name and artist and text that to a friend. Knowing this, Bolaji and the team started thinking of how to streamline this, by having the user share their song using the least number of clicks possible.
When taking a screenshot and sending the image, the user will have to click for the screenshot → navigate to their messenger app → search for the screenshot → then actually send the screenshot. This experience would take at least 5 clicks. When thinking about Annie the goal was to allow a user to share their music in under 5 clicks.
The takeaway here is, if you have a solution that doesn't offer a better experience, then all you have is a new shiny solution, which really doesn't have anything to offer that's better than the existing user experiences. To get users to use your app you want to give them a demonstrable better experience. So it is very important to do your homework in regards to existing solutions in order to have a competitive edge/advantage. It may also lead to more insight into the problem, as you will take time to understand why the current solutions have been architected in a certain way.
Given that we now understand the problem, and have identified and studied existing solutions we need to figure out how we want to solve the problem ourselves.
For Annie, Bolaji and the team figured out that users aren't able to share songs easily. The problems users have while sharing included;
- If person A wants to share a song, eg. 'Champion' when telling person B about this song, person B types in the name Champion onto their streaming platform and they find 10different songs going by that name. How does person B figure out which song person A meant to share?
- Sometimes when listening to a song you do not know the name of the artist. To figure out which song this is you first need to Shazam it, then send it to the person you want to share it with. This can be a pain as you end up having to juggle between multiple apps to share a song.
- User error - misspelling of artist and song names
- There are many streaming services and to share a song you might have to first establish which streaming service person B is on before being able to share a link to the song.
In comes Annie, given a song, Annie doesn't just provide a Spotify link, apple music link, or a Deezer link - she generates a generic link that can be used on all the streaming platforms. So basically, when sharing music you don't have to first establish which streaming platform the other user uses, with one link you can get the song on any of the aforementioned platforms. This is Annie's edge over the competition. With existing solutions, it's still a pain to share music because you have to establish which streaming platform you want to play the music on. People who share playlists, traditionally have to create the playlists manually on each of the different streaming platforms they want to share on. As you can already tell, that is a big pain that Annie is going to be a solution to.
Now that we have the solution, it can be very tempting to jump right into building it. However, you need to take time to figure out the direction you want to take when building the solution. During this stage, we want to take off our software engineering hats and put on our product owner hats. You could alternatively hire a product manager on your team.
Having a product plan helps us at the early stages think about why we are building the app in a certain way, the tradeoffs we have on decisions we make early on. For example, we might want to look into whether we want to build an app for mobile rather than web initially, thinking about these things early on and making informed decisions will in the long run increase the chances of making the app a success.
Build an MVP (or proof of concept)
This gives you confidence in your product. It's the most lightweight version of your solution. It doesn't have to be perfect, just a working version of the solution.
Test it out with friends and colleagues
With the MVP, you can share it with your friends and colleagues, to get feedback both positive and negative. At this stage, you can tell whether people are actually interested in using your product. It's a good way to dip your toes in the water and test out whether your solution actually works.
As people use your app, from their feedback you can iterate and make your app better. With the product plan in place, you can also easily sleuth out which feedback is relevant to what you are building and add the ones that fit your plan into the product development schedule.
It's important to focus on your core solution, make it perfect, before trying to look into other related areas. The product plan should keep you in check on the initial idea and the areas you want to focus on.
Annie is currently on its 5th iteration. With the first iteration, you had to manually share the link to a song by copying it from the streaming platform into Annie. From user feedback, the team learned that this was a pain users were having and enabled the sharing of links directly from the streaming services into Annie. Note that the iterative way of building an app allows you to make improvements while still having a pulse on how users feel about what you are creating. This guarantees that your solution is effective and actually gets used.
Focus on the problem you're solving and solve it well!
