Sell your project to your development team

All you really need is a good idea… right? Wrong! A good idea is just the start of your journey. For your dream to come true you need people who can help you turn that idea into reality.

Most entrepreneurs in today’s world have to cross a lot of bridges to turn their vision into an actual money-making product. Research, funding, investment, development, delivery, marketing, user engagement, user feedback, support, and then, when you finally see the light at the end of the tunnel, the money runs out and you start the cycle again.

One of the first tools you’ll need is a killer sales presentation to back up the sales pitch you have for your investors. This presentation gives an overview of your idea and focuses on all the points that investors want to know. But what most Product Owners fail to realize is that most of that information is crucial for your development team too. Having an overall view of your vision is extremely important when trying to find technical ways to make your product a reality.

Here are a few key things that you should take from your sales deck and re-use on a presentation for your development team.

What are you trying to solve?

Solving problems
Any great software idea comes from the need to solve a real world problem. Some are more technical, others more mundane. Some are simple, others complex. Some affect the entire world, others affect a very small set of people.

“How can we improve the taxi experience from the customer point of view and, at the same time, reduce the service cost?” or “How do we cut the time spent on repetitive tasks for company X by half?”

It really doesn’t matter. What is important is that you have a specific problem that needs solving.

Sharing this with your team before anything else, sets the tone for what follows. Analysts, developers, and consultants will immediately start answering that question in their minds and applying their specific set of skills to your problem. This is a great way to start a brainstorming session with the purpose of gathering requirements.

Real world examples

Just asking the question is good but it’s not enough. Now you need to engage everyone and prove that the problem you are trying to solve really exists. To accomplish that, nothing better than some real world examples. Describe situations like “Jack, a mid-class musician, in a new city has no idea how the taxi system works. He’s in a strange part of town and really doesn’t want to get ripped off by the local taxi drivers. Wouldn’t it be great if there was an app on his mobile that would help him find the closest driver available and at the same time show him exactly how much he’s going to pay for the ride?”

These examples serve multiple purposes. Your Business Analyst will start describing user stories for Jack in his mind. Your developers will start thinking on how to integrate maps, calculate routes and ride costs. Your UX consultants will build upon the Jack persona and discover other features that Jack is interested in. And the entire team will be convinced that your problem is important and worth solving.

Know your competition

At this point, the most negative members or your team are thinking: “Yeah, there’s already an app for that.” or “I fix that problem using App A and App B”. That’s why it’s important to focus on your competitors. If there’s another application (or set of applications) that solves your problem, then you need to show your development team that you did your homework and you are aware of their existence. All problems have multiple solutions and even if you find no other software in the market for your specific case, you will definitely find out how people solve your problem by other means and using other tools (i.e. phone calls, emails, search engines, spreadsheets, post-its).

Explaining how the problem gets solved today is important because it limits the thinking of your development team. If you have a problem that gets solved with a phone call then it makes a lot of sense that your app will be mobile, however, if the problem gets solved with a spreadsheet full of numbers, then it is probably better to think about your solution as a desktop app, where the keyboard and mouse are the preferred input method.

What makes you different?

Now that everyone is aware of the overall problem and how everyone is trying to fix it, it’s time to differentiate yourself from the rest. Explain your Unique Selling Points, highlight your cool features, let your development team know where’s the magic. If your application’s goal is to minimize boring spreadsheet-like tasks then highlight automation, explain features that will save the user’s time. If your app aims to solve an availability and convenience problem, then explain how effortless and fast it is, how the app magically knows what the user wants.

Remember who you’re talking to. These are not money people, they are extremely technical and will call you out if you just start “selling” your system as pure magic. Be ready to back that magic up with some realistic ways of implementation.

What’s your Business Model?

Sharing your business model with your development team might not seem important at first, but it couldn’t be further from the truth. An application that generates revenue based on subscriptions or one-time purchases, is completely different from one that uses advertising or sponsored content. Your team needs to be aware of how you plan to make money, how many users/purchases it requires to “break even”, what markets is the application targeting, will the launch be global or localized. All these factors influence their focus when gathering requirements and finding solutions.

What’s your Road-map?

And finally, your development team should have a clear understanding of the overall road-map. You should inform them about go-to-market deadlines, incremental developments, rounds of funding, and new markets. This type of information will allow your development team to recommend you the best way to scope and organize the features of your application. If you plan to go global in a year but for now you’re focusing on the US market, there’s no reason to spend time handling translations, currencies and country specific features right now. At the same time, if your next round of funding is in 6 months, it is crucial that everyone works towards having a stable user base by that time while leaving a few cool new features to implement right after the funding is secured.

Don’t be afraid to share information

As the Product Owner, it is sometimes challenging to know what to share and what not to share with everyone involved in your project. Don’t be afraid to share information with your development team, they are responsible for making your dream come true and you will benefit immensely if you let them know your full plan.


Daniel R.

PHP developer and consultant. Enjoys solving problems, building apps and (occasionally) breaking stuff. Currently lives in Poland and works for an american startup focused on data-gathering.