Behind every innovative software company is an R&D department. This department is staffed by engineers and tasked with developing new products, and is exactly where you and I belong. Although both research and development are equally important in R&D, some of us tend to under appreciate the research portion, while others can severely over emphasise it. Regardless of how much a company may be willing to invest into research, it absolutely must make money to survive. Software companies are very rarely in the business of selling good ideas, as the name implies, they typically make their money by producing software. Therefore, what we should aim for is just enough focused research that will enable us to create smart, simple solutions, no more, no less.
There is a reason why R&D is not called: “D&R”. Before you are able to develop a solution to any one of your product wish list items, it is essential that you first fully understand the problem. You have to grasp the “what” completely before you can determine the “how” and “why”. Without knowing exactly what it is you’re trying to solve, you can not possibly understand how to solve it, nor be able to justify why your chosen solution was the best approach. The other great advantage to research is that it can help steer you away from the clichés, and result in solutions that are more smart than obvious. At the same time, you should avoid doing too much research as this can lead to solutions that are more complex than simple.
I am bringing this up now because I want to emphasise that research comes before development, and therefore should be considered as early as the design phase of your project. Exactly what to research and how much of it will be needed can be determined as you tackle each problem, but the aim of this step is to determine which wish list items require more research than others, then plan to include that research as part of the development.
Assign each item in your product wish list a rating out of 5 on how much previous experience you’ve had with these types of problems. For example, a rating of 5 indicates that you have solved this exact problem before and can almost entirely copy and paste the solution, whereas 4 could imply that although you have solved it before, it was written in a different language, or was based on a technology you will not be reusing. Now invert the ratings by subtracting 5 from each and removing all negative signs. What you should be left with is a research requirement rating from 0 to 5 per item. We will flesh out the details of these research tasks later in the development phase, but for now we at least have a rough idea of how much research will be needed to solve each problem relative to one another.