Project Blueprint Guide

Published Jan 08 2019 04:59 PM 87 Views
First published on MSDN on Nov 13, 2014

What is a Project Blueprint?

The document we are calling a " Project Blueprint " is something we have invented for this contest. It's not something that exists by that name in real software development. So why are we asking you to write one?

We looked at a wide variety of the tools, documents, and methods real software teams use for creating their projects. Every team does things differently. We know there is no one perfect way for getting a project planned and started. But what we do know is that there are some ideas many teams use which you should know and understand. That includes concepts such as target audience demographics, business model, user personas, competitive analysis, early concept feedback, and user stories. You may already be familiar with some of these. Others may be new to you.

At this point, you may be thinking, "But I'm a developer! Why should I be writing all this business model and demographics stuff? I just want to start coding!"

I have two answers to those questions:

  1. Small teams and start-ups require people to do multiple jobs. You may be a developer who also has to design your product's website, or you may need to write a business plan in addition to getting your code done. In larger teams and larger companies you may have the luxury of just doing one thing really well -- but you can't count on that. The more diverse your skills and experience, the better a job you'll do no matter where you work after graduation.

  2. You don't have to do all that! A good team is cross-disciplinary, which means a team isn't just developers. At a real company a team may include testers, project managers, UI artists, a business manager, a marketer, and other roles. If you don't feel like you have the knowledge you need to fill out everything in the Project Blueprint, go find someone! Your college or other colleges nearby probably have a business school, a design school, a marketing school, and so on. Your team will be stronger and your project better if you get help from other students who have expertise in those areas. And if you're worried about the fact that Imagine Cup teams can only have four students, it's no problem. Please read our Official Rules for the section on Teams, Associates, and Mentors where you'll learn about how your team can have associates. These are students who help your team out in any of the following areas:

  • Business Planning

  • Video Production

  • Graphic Design

  • User Experience Design

  • Music and Sound Design

  • Testing and Quality Assurance

  • Marketing and Social Media

So that's our big secret: your Project Blueprint isn't just about putting some real thought and effort into your project before you even write a line of code. It's also about ensuring you have the right combination of team members and associates to make your project the very best it can be!

Writing Your Project Blueprint

When you download and read our Project Blueprint Template you'll see eight main sections to fill out. Each section has a short explanation but here is some more information and useful links that will help you make the best Project Blueprint you can.


Explain what your project is. This section should be a paragraph or two. If you're still working on your concept, you might find the following links helpful:

Target Audience

Tell us who your project is for! "Everyone who uses a computer" probably is not the right answer. Maybe your target audience is college-age music fans, or maybe it's people in rural areas who need access to severe-weather emergency information. If demographics such as age, location, gender, or other elements are important to your definition of your target audience, tell us! It's also very helpful to explain approximately how many people you believe are in your target audience. Here are some useful links for demographic data that might help you estimate the size of your target audience:

Early Feedback

Did you know that some start-ups test their projects with real users even before they've written any code? That's because they know you can get useful feedback when you're still just at the concept stage! These start-ups find either potential users or people who have expertise in the area of the project and they simply explain and discuss their concept with those people to get early feedback.

Some go even farther. They create a website for their concept that just says something like "Thanks for visiting, coming soon!" and then they pay for search engine ads that offer their concept as if it really existed. By analyzing the traffic their website gets and by adjusting the way they pitch their concept in the search engine ad, they get valuable data on what their potential customers will respond to. While we don't expect you to pay for ads just to test your concept, that's an example of how you can get early feedback on whether your concept is even the right idea.

For your project, think about your target audience. Do you know anyone in that audience? If not, can you find some people like that easily?

In addition or instead, you can find someone who knows a lot about the topic you're exploring. If your concept is for an app that helps field workers test people for malaria, find someone who either knows a lot about malaria or even someone who has worked in places where malaria is a problem. They could give you great feedback about your concept and what your priorities should be.

Here are some links about early feedback that may inspire you:


It's important to know who your competitors are. You should explain here what your major competitors are and how your project will be different and better. Please note that depending on your project, your competitors may not be other software solutions at all. Think beyond your chosen platforms and ask whether you are competing for your target audience's time, attention, and money in other ways. Doing this kind of thinking and research is known as Competitive Analysis. Here are some related links:


A persona is a fictional person you create who you think represents your target audience. Personas are common tools in marketing and user experience design but are also finding usage in software development. You invent a person with a name, location, age, gender, job, family, and so on. How skilled are they with computers? What platforms do they use? What needs do they have that are relevant to your project?

Earlier in my career I was a videogame designer working on a massively multiplayer online game for the PC. We created two personas. One was a PC gamer with a lot of experience playing MMO games. The other was also a PC gamer but with only a little experience playing MMOs. We gave them names, photos, families, and lists of games they really enjoyed. We briefly described their friends and what games they played together. From then one, when we were working on plans for features and prioritizing them, we would ask each other how and whether these two personas would use that feature. It gave us all a common reference point and a way to ensure that our work on the game was directly serving the needs of these two hypothetical users.

You can learn more about personas here:

Top User Stories

Agile development has become extremely common in the software industry. This is a method for planning projects by creating "user stories" in a database called a backlog. The team then prioritizes those user stories and breaks each one down into specific tasks. Then for a given "sprint" or period of work the team decides which user stories and tasks to work on. It's a very useful method for software development and it begins by creating an initial set of user stories. These first user stories are generally the biggest and most fundamental. They are sometimes called "epics" because they are so big and will later be broken down into smaller pieces that are ready for implementation.

There's a good chance that you're learning about agile development at your school. We're asking you to come up with a handful of your most important user stories so you can start thinking about your core functionality and how you will confirm that it does what it should. For more about writing user stories, please read these articles:

Business Model

Your business model is how you will make money from your project. Even if you are making something to help people, you need some way to pay for ongoing support and development for the project. That may mean it's given away free but that your project gets funded through grants or partnerships with charities. If you do intend to sell your software to users directly there are still numerous questions to address here, such as how much you will charge and when. These days the software industry has developed many ways to charge money from software other than just buying it up front. There are subscription models, there are free trials, there are microtransactions, and more. These alternative models have become especially popular in online games, web games, and mobile games but they are now common in productivity software as well. Consider Adobe's Photoshop and other software for design professional, which used to sell for hundreds or even thousands of dollars and is now sold as a monthly subscription service.

Here are some articles about these alternative business models. While they are mostly about mobile apps these models are also used for web sites and services as well as desktop software:

Core Technologies

This one is easy! Just tell us the platforms you will use and any middleware, libraries, or game engines. If you're making a Windows desktop project that uses Kinect and the Unity game engine, for example, explain that here.


Whew! Okay, that's a lot to digest. But I guarantee you one thing: if your team puts in the work to understand and complete a Project Blueprint, your project will improve substantially and you will end up with a much better and more competitive entry in our other Imagine Cup competitions.
Version history
Last update:
‎Jan 08 2019 04:59 PM
Updated by: