This article is part of the She Hacks Academy (a hackathon training program for women, by women) where we write about different topics that might help other women participate and thrive in hackathons.
G’day. One of the first things you have to do at a hackathon is develop a product idea. Here’s a strategic approach for planning and testing your idea.
Contents
- Sketch the Product Idea
- Research the Current Scene
- Know Your Critical Mass
- Check Reliance on Third Parties
- Validate Your Idea
- Plan the Minimum Viable Product
- Consider Your End Goal
1. Sketch the Product Idea
OK, so first of all, you’re going to come up with an idea.
Maybe you just have an idea one day… “I want an app that does X! Why doesn’t it already exist? Heck, I’ll make it!”
Or maybe you’ve had an idea for something that could be profitable… “If I could improve staff satisfaction and retention in companies, well, companies would totally pay for that service.”
Or maybe you’re at a *hackathon* and you’ve been given a topic, like “My Neighbourhood” and you start thinking about issues in neighbourhoods and writing down ideas, like:
- How it’s hard to find a babysitter
- How you need to find an electrician and you don’t know where to start looking, but you’re sure that people in your neighbourhood must have recommendations (and warnings on who to avoid)
- How you’d like to volunteer locally and you’re sure there are opportunities, but you don’t know how to find them
Anyway, let’s start with the idea. Here are two examples.
Example Idea A: Refera
Let’s say our idea is “Refera” and it’s based on the user need, “How do I find a good electrician (or other service provider)?” This is the concept so far:
- Electricians and other service providers want more customer referrals.
- When a service provider completes a job, they leave a request for feedback with the customer that says “I would really appreciate if you could rate me on Refera. Leaving feedback will get you 10% off your next service!”
- The customer leaves feedback on Refera. While they are using Refera, they see they can look up any kind of service — from hairdressers to kitchen renovators — and see how they have been rated by other people.
- Because the customer had to give their email address when they left feedback, Refera can now send them a bi-monthly email newsletter that has interesting content with recommendations, which helps keep Refera top-of-mind.
- 2 months later, the customer’s brother is desperately looking for a plumber, and the customer suggests that they use Refera to find a recommended plumber.
Refera Sketch
Example Idea B: Ladytime
Let’s say another idea is “Ladytime” and it’s based on “I want an app that does X!” — your own personal needs. This is the concept so far:
You’re female and you’ve tried a bunch of iPhone apps that are supposed to…
- Remind you to take the pill.
- Allow you to log periods so you can predict when your next period is due.
- Give you helpful related information, e.g. When you are ovulating, because that’s when you’re most likely to be extra confident and outgoing
…but they’re all terrible! You’ve tried maybe 15-20 of these apps over the years, and they have such bad designs and bad user experiences; some of them crash or have bugs that make them useless; some don’t have the simplest of necessary features (like being able to edit something after you’ve added it). So, you’ve decided to make Ladytime, an app that does everything you want it to, and it will also be beautiful to use.
Ladytime Sketch
2. Research the Current Scene
Do a search on your idea and see if someone’s doing the exact same thing. See if there’s anything else interesting being made for this user need. Find out how busy the market is — Is this a hot topic for startups, and you’ll have lots of startup competition? Or are you competing against some established players?
Have a think about how people are solving this problem already.
Let’s look at our product examples, Refera and Ladytime::
Refera Research
Maybe people use Yelp to find service providers. Maybe people post on Facebook and ask their friends to recommend an electrician. Maybe they ask their colleagues. Maybe they use Google, or Yellow Pages (which has reviews, but hardly any). Write down all the possibilities, and give them a go. Will Refera be able to compete with the ease of using Facebook to ask friends? If Yellow Pages can’t get anyone to add reviews, how will Refera?
Search for keywords relating to your idea (like “rating search providers”, “rating electricians”, “electrician recommendations” and so forth). Maybe you’ll find a Mashable article and a TechCrunch article that are both dated 2012 and talk about the launch of 3 new products that help customers find service providers. Then maybe you click through to those products, and they no longer exist… and so you dig further and find out they went out of business, because they couldn’t make money. Uh-oh!
Sometimes, even at this research stage, you might feel you need or want to change your idea.
Ladytime Research
Well, the whole reason we came up with the idea for Ladytime is because — while the market is crowded — the apps that are currently available for period tracking are either hard to use, broken, or don’t have some key necessary features. We’ve done our research on this one, and we’re prepared to enter a crowded market!
3. Know Your Critical Mass
Imagine this is a timeline of a product:
It’s likely that when you’re thinking about your idea, you’re thinking about the second half of the product timeline: Post Critical Mass. In your mind, people are happily using your product, and it has all of its essential features, and everything’s going well. Of course, we need to have a vision like that… but let’s think about critical mass for a second.
What sort of critical mass does your product need? We need to look at every human that needs to be involved, for your product to be chugging along fine.
Let’s check our example products, Refera and Ladytime:
Refera’s Critical Mass
For Refera to be successful, it needs to have a critical mass of service providers, and a critical mass of customers (general public) using the product.
Service Providers
Refera needs hundreds of services on board. Users won’t use Refera to look up electricians if there are only 2 electricians on Refera, because they won’t feel like it’s providing them with real choice or real recommendations. (Note: This is a big assumption. We need to collect all our assumptions in a document, so we can come back to them later.) One option here — to reduce the critical mass required — would be to give the service a niche focus. We could start Refera in one small area, and concentrate on only having certain service providers to begin with, e.g. services for your house.
Customers (General Public)
Refera also needs hundreds of customers on board. Service providers aren’t going to sign up or hand out requests for a Referra rating after they’ve done a job unless it’s going to get them more customers, so there needs to be an active audience of potential customers. And customers won’t use Refera if there are no other reviews and ratings on the site, because they might as well use the Yellow Pages or Google! Customers are also probably less likely to use the site, or add content, if they think it’s an unsuccessful product… a graveyard of inactivity. (Note: A bunch of assumptions.) Again, we could try for a niche focus, like initially targeting and launching the product for mums only, but we’d have to think that through, and see if it would provide enough activity (and potential customers for the service providers) to work.
So:
Refera has a problem with the critical mass. Unless we go for a niche focus (potentially, one niche for service providers and one niche for customers), it likely needs hundreds of **active** service providers and **active** customers. And **active* is a big ask… sometimes it’s easy getting a lot of signups (especially if you have a lot of funding and publicity), but if people don’t actually keep using the product, all those signups are useless!
This is a real “ALL IN!” product idea. It doesn’t matter how many people say the idea sounds great, or how many friends say they would use it, or how many email addresses you collect on a “coming soon” page… this product needs a high critical mass of active users before it will actually **work**. (Unless you’re a millionaire and don’t really care if it fails. Then, by all means, build it to match the product you had originally and beautifully envisioned!)
Ladytime’s Critical Mass
Ladytime is providing calculators, reminders, calendars and other widgets to individual users. The app will still be effective and useful if one person is using it, or if ten thousand people are using it. And, because it’s an iPhone app, if we’re interested in sales of the product, we only need people to buy it — they don’t even need to be active users. So, we need a medium critical mass of purchasing users. If we had in-app advertising or in-app purchases, then we might want a medium critical mass of active users, too. Or we might want a medium-high critical mass of active users so that we could sell the branding rights (or sell the whole app) to another company, e.g. Libra.
Refera needs hundreds of service providers and hundreds of customers who are active users. Ladytime only needs to meet our requirements for app sales. If, for example, there was a Ladytime Lite version with fewer features, and Ladytime full version with all features at $4.99, and we figured that 1000 sales per month would be a nice earner, then we need to figure out if women would be likely to a) try Ladytime (Lite or full) and b) buy the full version because it proved to be useful enough. However, Ladytime might only ever be a pocket-money earner, whereas Refera could become a full-time company and job.
4. Check Reliance on Third Parties
In a hackathon, we’re encouraged to build mashups and to utilise existing platforms, APIs and other sources, a) so that we don’t have to build something from scratch, and b) so we might make something new and cool (like IFTTT!) from combining existing items.
This is fantastic, of course, but we do need to check how much we’re relying on third parties, so that we can decide:
- Are we OK with this reliance?
- Can we diversify at all, so that we’re relying less on these third parties if they become unreliable?
Two internet greats, Jason Kottke and Marco Arment, have both spoken about their experiences with building web products that have heavily relied on third parties.
Highly recommended viewing:
Jason Kottke — I Built a Web App at Webstock ‘13
.
.
.
Marco Arment — Fear and Competition at XOXO Festival ‘13
.
.
.
So, let’s check our product examples for reliance on third parties:
Refera’s Reliance
Refera’s reliance depends on how we build it. If we connect it to a bunch of other systems, like Yelp and Foursquare, then we’ll need to be prepared for any unreliability that comes from that. But if we’re focusing on building our own database, with our own customers and our own reviews, then we could use other platforms & services to boost our content and usefulness, while knowing that they’re not integral to the performance of our product.
Ladytime’s Reliance
Likewise, Ladytime could be built with a focus on its own database, customers and content, only using other platforms & services to boost the product. One competitor, “Glow”, integrates with platforms like Fitbit Flex and Jawbone UP, and we could also consider those integrations if they made sense in our product vision… but we’d have to make sure that the extra time and effort we spend on any integrations is really going to be worthwhile.
5. Validate Your Idea
OK. You’ve got your idea, you’ve done your research and critical thinking, you know your critical mass, and you’re not relying entirely on third parties. What next? It’s time to validate the idea.
The best method (and — disclaimer — I’ve only been working with startups for 6 months, so I still have lots to learn!) I’ve seen for this is the
Javelin Experiment Board (free!).
Unfortunately, the team at Javelin haven’t made it really user friendly, so you’ll need to download the templates (see link above) and then watch the tutorial.
Javelin Experiment Board tutorial
I recommend watching a couple of the case study videos, too:
.
How FashionMetric Pivoted to a Problem Worth Solving
.
.
How Jennifer learned her way to a big business
.
.
Then gather your team, and start filling out the Javelin board… and do your first test!
The team at Javelin also have a new product, called Experiments, which is current in beta. The tool is based on the Javelin Experiments Board and costs $29/month.
6. Plan the Minimum Viable Product
I could sketch out how to plan the MVP, but someone else has already said what I would say…
Please read Will Dayble’s post Minimum Viable Product, which is fantastic and looks at planning the product with an initial user flow, then simplifying it to the max. It’s great advice, and really helps with planning your workload and priorities in a hackathon.
Here’s an example of my team’s MVP planning at She Hacks ‘13.
7. Consider Your End Goal
Last, but not least…
Yes, this is a hackathon, but you might be thinking about building this product for real, or it might be a startup hackathon where you’re all building real products.
In any case, it’s worthwhile to pause for one moment and consider success and your end goal.
- What does success look like, one year from now? Say the product is so successful that you’re working on it full-time, fixing bugs, working on new features, doing interviews, providing customer service to your users, etc.
- Are you that passionate about the product?
- Will it keep your interest full-time?
- What will your day-to-day tasks be, once the excitement of having launched a successful product is over?
- Do you want to focus on this one product or diversify into other products?
- Will you have a great data plan so that you can sell data?
- Will you look to be acquired?
What’s next?
Alright, that’s a lot of planning and testing! I’m guessing we’re good to go with our product idea now. What’s next? Designing, coding, hustling, knuckling down and having fun!
Continue to the She Hacks Academy collection for more articles related to participating and enjoying a hackathon.
