One of the early chapters in my book (A Practical Guide to Web App Success) discusses the factors that influence the success of an app, such as the idea, the quality and speed of execution, and the wider context in which it’s situated: the competitive landscape, the levels of technology adoption, the financial climate and so on.
While the book includes some quick and easy ways to validate a concept, I don’t really talk a great deal about the initial genesis of ideas, as I assume that most people who buy the book already know what they want to build.
This post fills that gap. It is written for those of you who have the enthusiasm to build an app, but first need a good problem to sink your teeth into.
Most of us spend at least eight hours of every weekday at work, solving problems, transferring knowledge and managing processes. Our wages are usually based on how quickly and effectively we can do these things, as quantity and quality are two key variables that affect business profits. If you can think of a way make a business process more efficient or generate more value in the same amount of time, you’ve got a fundamentally sound app idea.
Unfortunately there is little tangible diversity in the daily experiences of most web app developers. This is one reason why you see a steady stream of new MVC frameworks on Hacker News – we have similar jobs in similar environments, and therefore create similar solutions to similar problems.
Less than 1% of workers in the US are software engineers [data 1 and 2], yet we initiate at least 90% of web app products (a conservative guess). This is the equivalent of most magazines being written by printing press operators – though come to think of it, that would produce more interesting results than the current stable of celebrity cellulite shitfests.
It doesn’t necessarily matter if you pursue an unoriginal idea, but in some ways it makes it more difficult to have a real impact: you’ll face apathy from the market and a prohibitive amount of competition that includes free and open source options. Unless you’ve secured the funding necessary to force your way into a crowded market, it’s better to seek opportunities that at least have a smidgen of something new and that customers have a pressing need for.
If you work in a small company or startup, you’ll naturally wear many hats and will face a variety of non-technical problems. Keep your eyes peeled for tasks that can be automated or improved with web technology.
If you work in a large company you should seek out similar opportunities, but you’ll need to proactively find a way to work with other teams (sales, design, marketing, finance, human resources) to step out of the programming sphere and find fresh problems to solve.
As director of a growing web company for eleven years, I got to discover many problems that are still in need of solid solutions. Here are two examples to get you started.
Example: Responding to tendering opportunities is costly. Large contracts from the public and private sectors are often put out to tender. If a company wants to win one of these valuable contracts, they must respond with a high-quality documented response, which will run to hundreds of pages, though much of it can be boilerplate or customised boilerplate text and diagrams. The value of a contract is often hundreds of thousands of dollars, so it’s worthwhile for the company to spend days or even weeks preparing the tender response, which is incredibly costly, but a necessary risk of winning work.
Over time, a company will create dozens of boilerplate/template documents/answers/snippets that they can re-use in tender responses, but these are often stored in myriad Word documents that need to be manually managed, collated and customised.
There is an opportunity for an app that stores various reusable document components that can be easily discovered, selected, customised and aggregated to produce a tailored, professional tender response. If a company tenders for two projects a month and you can reduce the average tender response time from five days to three days, you’ll save them thousands of dollars a month, at minimum. What might a company pay for that kind of saving?
Example: Assessing good job candidates is difficult. There’s no obvious solution to this, which is why it’s still a problem. Every company knows that their hiring process isn’t perfect. They’ll take on employees who won’t pass a probationary period (costing the company thousands of dollars in wasted training) and will pass on candidates who should have been accepted (costing the company potentially tens of thousands of dollars in opportunity costs).
There are a few partial solutions to this problem (such as LinkedIn and Stack Overflow) but these are industry-specific and not applicable to all candidates. If you could develop an app that helps employers (perhaps in a specific industry) to improve their hit/miss recruitment rate by even 10 or 20%, you’ll save them thousands of dollars a year, and probably a lot more.
When you’re not in work you’re cooking meals, paying utility bills, socializing, pursuing hobbies and fitness, seeking entertainment, traveling, and so on. Adopt a critical mindset for a couple of days to identify areas that could be improved, bearing in mind the types of task that web apps are useful for, such as automating recurring processes, detecting patterns in data and bringing together supply and demand.
Think creatively, and question anything that doesn’t seem quite right from the second you wake up. Feel tired after a restless night? Maybe there’s a way to detect a pattern in your habits and environment to improve your sleep. Throwing away junk electronic equipment because it’s not worth your time putting it on eBay, Craigslist or Freecycle? Perhaps there needs to be an exceptionally low-friction app that can list it for local pick-up within seconds. Annoyed at the garbage that people leave on your street? There may not be a web app answer to that, but maybe there is if you give it some thought. It sometimes helps if you first consider what the perfect “magical” solution would be, ignoring technical limitations. From there, work back to the closest you can get with current technology.
Here’s a more concrete example.
Example: The system for buying gig tickets is broken. We all know it. Many popular venues only list tickets through large corporate ticket vendors, and the final price always seems to end up costing 50% more than the “face value”. There are some complexities at work here (it is often the venues that impose the ridiculous additional fees, not the middle-men), but that doesn’t make the system any less broken to the customer. In addition there are people who buy multiple tickets for no other purpose than to restrict supply and inflate the re-sale value of their own tickets.
So, while there are a number of upcoming gigs at The Fillmore that I would like to attend, I’m not willing to pay the absurd extra fees for bands that I’m only partly interested in seeing. What some of my friends and I do is wait until a day before each gig and then scan Craigslist and eBay for spare tickets. For most gigs, we’ll find tickets at face value or sometimes less. However, we still have to manually set a reminder for upcoming gigs and then scan the websites for tickets a day or two before (or sometimes on the day of the gig itself). An app could make this more efficient, by helping to match supply and demand.
If your primary purpose of building an app is to make money, it sometimes makes sense to copy an idea that’s already proven rather than strive for originality. As Zynga’s CEO Mark Pincus is alleged to have said, “I don’t fucking want innovation. You’re not smarter than your competitor. Just copy what they do and do it until you get their numbers.”
You could investigate small (easy to replicate) profitable web apps and copy them feature-for-feature, but for reasons I’ve already stated, I’m not a fan of blatant facsimiles. If you can add a slightly new take on a tired concept you stand a better chance of success.
A simple way to do this is to find a large piece of software and think about how it might be adapted to better suit specific industries; Eric Reis and Steve Blank would refer to this as re-segmenting a market by niche.
Think of how Kyle Bragger’s Forrst took the idea of a generic social network and re-segmented it for graphic designers and programmers. How would you do something similar for your occupation or interests, such as a social network for musicians to share riffs and ideas?
Example: Basecamp for authors/publishers. 37 Signals’ Basecamp is the leading project management and online collaboration tool, partly because it’s well-designed generic features make it useful for a wide range of industries. But this also means that it isn’t tailored to any particular type of business.
My publisher, editor and I used Basecamp to communicate throughout the book authoring process. While it certainly helped, it could have been improved for our particular use-case. Small publishers and distributed authoring teams need a system that better handles revisions between files, and in general something more suited to iterative tasks rather than linear discussions. It would also be useful to have a file repository that treats various assets – documents, diagrams, screen captures, raw data, sources – differently, and one with greater control over the structure and relationships of discussions, files, milestones and to-dos. But it also needs to be extremely simple and tailored for the publishing process, not just a shoe-horned version of GitHub or Redmine.
Even Magma, which handles “print publication management” and according to Techcrunch is a “Basecamp-like platform oriented towards magazines and print publications”, is aimed at a slightly different segment of the market. There are abundant niches to fill in almost every market.
This isn’t my preferred approach to idea development because it’s technology-led rather than originating from a real market need. Still, it might help to get your creative juices flowing. A quick way to start thinking about the application of technology is to write a list of recent web technologies that interest you on a piece of paper – web P2P video, canvas/WebGL, geolocation, data mining algorithms, and so on – randomly choose two (close your eyes and place your finger on the list), and think about how they could be usefully combined.
What do people say that they want? Social media and web apps like The Internet Wishlist make it easy to find out. Check out Google search suggestions to discover what software people are looking for (e.g. 1, 2), and try creating some convoluted Twitter search queries to find tweets with app ideas. Most will be in jest, but you’ll sometimes find some genuine needs hidden in the noise, and even the humorous suggestions can inspire a practical related app idea.
This post outlines different sources of inspiration for web apps. Once you’ve chosen an idea, give it a few days to mull-over and slowly iterate the concept. Rather than gradually expanding on the initial idea, try to stick to the essence of it while you remove imaginary features and scope. Most of all, try to choose an idea that excites you – it makes the development so much easier.