5 Questions for Biz Folks with a Good Software Idea

Recently I’ve been getting coffee with bootstrapping tech entrepreneurs here in Chicago while offering up some free advice and receiving some in return. Often, non-technical folks have great ideas for software products, and as a developer, I can attest that our ideas are sometimes — ok usually — awful, so we need domain experts to guide what needs to be built, and to articulate what problem needs to be solved. Having been writing software for over ten years now, I’ve gleaned a bit about early signs of a successful software project, but I’ve also noticed in my conversations that it’s hard for non-technical founders to understand when an their idea is “shovel ready.”

If you go and hire a developer or CTO too early, they might not have anything to do if you haven’t gotten the following five ducks in a row. Or, worse, your new employee will start building, and charging you for what will become an expensive flop.

Pictured: Startup founder wondering what they need to build a successful software product.

Here are some questions you should have answers to before you start involving the technical folks with their construction “shovels”:

1. Who will be the first user?

This is not an abstract question in search of a “persona.” Know their name, have their email, make sure they’re on board for a wild ride. The hardest part of writing software isn’t getting the stuff to work, but rather it’s making sure what you build actually fits into the constraints and meets the expectations of real human beings. Without user feedback, a software project is doomed for failure.

Go outside the comfort zone of your personal acquaintances to locate a real user (meaning someone willing to be critical and not someone doing you a favor), and get her or him to sign up enlist her or him for a beta. Before trying to do so, it is highly recommended that you refine your marketing pitch and then put-up a signup page (you can use carrd.co for that). If you can’t get a single user to get on board, it’s likely you’ll likely need to refine your value proposition.

Once you do have someone whom you hadn’t known, reach out personally to thank them, and also try to have a conversation about what they’re expecting and what they would want. This relationship will be integral to the foundation of your product.

2. Who will it delight?

OK maybe your brainchild doesn’t have people skipping down the streets, but you do need to ask the question: Who (besides yourself) will your product make smile? If you’re going to invest months and probably years into creating something that you expect others, including users and stakeholders, to invest time and money in, it’s important that it brings some joy to the world.

Making a painful problem less painful isn’t enough. Users’ adoption of anything new, no matter how awesome its potential, necessitates adding to their load. Your challenge is to significantly lessen their load in some other way. People don’t smile when confused or when something is only marginally better than the status quo. Make it fun, or lift a great weight off someone’s shoulders, and you’ll convert them into your internal champions.

3. Where does the data come from?

The easiest type of application to write is one with no external dependencies- not pulling data from anywhere, just relying on what data the user generates independently. Example: a To Do List application.

If an application relies on external data, but it is open or publicly accessible, that’s pretty easy too. Example: a Twitter follower analyzer.

The two other categories are where the data comes from private sources, or where it is generated by other users (e.g., a social network). If your application will rely on data from private sources, do the research and start forming those partnerships before you go to build. Figure out the costs, see if you can get a sandbox account, and get the documentation. Developers quickly have nothing to do if they don’t have any the relevant data sources to integrate with.

If you are planning for much of the value of your product to be user-generated, for example Facebook or Stack Overflow, the probability is extremely high that your idea will fail (sorry!). You cannot start a new social network or crowd-sourced content site these days any more than you could go to the middle of the wilderness, shout, “There will be a city here!” and have it materialize. Figuring out how to meet the needs of that niche without relying on users to generate the value is the trick that works the big magic.

4. What are the three most important features?

Write out a backlog of features as “User Stories,” and prioritize them so that you have identified the top three. If nobody would use your product with just those three features, it’s likely you will need to do more work in refining your niche.

A user story is a software feature written in the form, “As a [user type], I can [perform specific action].” For example, “As a Trello user, I can create a card with text on it.” Or “As an admin, I can invite new users to my team.”

If your idea only becomes compelling once you’ve implemented all the features of Facebook, Mint, and Trello, you need to refine your it more. Having big ambitions for what it will eventually become is, of course, your right, but you need to have your core value proposition narrowly pinned down so that it’s feasible to build and ship in a couple months.

5. Web, Native, or Something Else?

It’s fine to have a long-term vision for a cross platform app, but realistically you need to have a better sense of what platform the application will first be deployed on before you can engage technical talent. It’s very difficult to build a fully optimized cross-platform app, even in this day of React Native and NativeScript. The reason is that even though the technical lift has improved in recent years, it still requires different design thinking to make the apps “feel” like native Android or iOS applications. It’s also a rare individual who has the breadth to build a truly effective cross platform app. In exotic cases, it may make sense to deploy the product in a different way, such as an Application Programming Interface (API), designed for consumption only by other developers, or a bot integrating with an existing platform like Facebook Messenger or Slack.

Generally, a responsive web application should be the default- the cost of acquisition for a native-only app is much higher. Knowing if you’re building a web app, native app, or something else isn’t a technical question; it’s about knowing your market and having a clear vision for the product, so be sure to have answers before you engage with a developer or CTO.