Updated: Sep 28, 2020
So, you have a concept for a software application. Perhaps you have a small team that includes a developer who has made use of open source to create a working prototype. Before doing much else, think about taking the time to professionalize your project, to support it with fundamentals.
This is the fun, externally facing part. You are going to want to create a Product Vision statement. Make it short. Who is going to buy your product? Who are the users? Whose needs is the application going to satisfy? What are the attributes of your application that satisfy those needs? How does your product compare against existing applications? Does your product have unique selling points? How are you going to deliver the product? What is the price? What is your target timeframe and budget to get to a beta launch?
Consider a few tools, deliverables, artifacts to help create the vision for your product. Elevator pitches to different users. A business model that highlights potential tradeoffs your company may have to make. Create a blog entry, or a press release. What do you want people to hear about your application? Create a prototype. If you are in alpha or have a beta running, then get feedback from your users. Give names, identities to your different users. Describe how your product will influence their lives. What about a product roadmap, and release plan? Create a parking lot.
This is the hard, internally facing part. Look to define the different ways your internal processes support quality. Think simple, light policies that describe such attributes as reliability, efficiency, maintainability, testability, flexibility, etc. Quantitatively measure one or two. Create standards; can you defend the status of your application against them? From the perspectives of production and customer satisfaction, what is the performance of your development process? Can you defend what (and why) you sacrifice when project variables (scope, schedule, resources, quality) change? It’s a closed system – if one gets bigger, the other gets smaller. How do you intend to define process variation? How do you manage defects? Verification and validation? Have you started the process of automating testing? Do you have the cost of Quality built into your financials; it’s ~50% of your development budget. When you deploy, keep in mind that the tactical portion is 3-10x more expensive in both time and cost than the design phase.
If you really do the above well, it should take about three months of dedicated effort. Afterwards, your project should feel different, more substantial. Answers are quick and defensible. This is my definition of ideation - it's practical, difficult, and rare in completion.