Don't forget the elevator pitch

---

Necessity is the mother of inventions, and of many software projects as well. The choice to develop new software is never a simple one, but it often starts with some specific core need or idea. Wouldn’t it be great if we had some software to do X? The relative simplicity of that initial idea can be very helpful in the early part of the project, where priorities are being set and potential pitfalls need to be avoided. If you can quickly explain why the software project is a great idea, why it will save time, or why it will offer your customers something valuable, then you have a good elevator pitch. And that pitch is worth remembering, since it can help keep the project focused and ensure that it launches quickly and successfully.

One of the more unfortunate aspects of developing software is that it can take a long time. It’s a profession where the man-months are mythical and the delays indefinite. The larger the scope of the project, the longer it takes. Thankfully these issues can be avoided completely by limiting the initial scope as much as possible to just the parts needed to deliver on the value promised by the idea that first inspired the project. Start by building a product which can prove the concept works. Of course, it’s not quite as simple as that, features don’t creep into the project scope because people aren’t aware they will push back deadlines and add risk; they creep in because it’s human nature to want more, and it’s hard to say no to extra features. By having the elevator pitch as a guiding force, starting with a limited scope is implied, and rapidly delivering a prototype that delivers on the pitch becomes the obvious next step.

If a project’s deadline is in six months, then in the worst case scenario where absolutely nothing gets done the project can be at most six months behind when the deadline arrives. In the same way a one week deadline can at most be behind by one week. Projects with large scope leverage this idea by setting intermediate milestones. But it can be difficult to pick deliverables that aren’t arbitrary and that accurately reflect the progress being made, and those descripiances can have a large impact on the outcome of the project. A simpler approach is to start with a specific prototype in mind, one that delivers as much as possible on the core promise of the elevator pitch, and to work as rapidly as possible toward building a working example. This results in the shortest possible deadline, and will allow you to discover any potential issues as quickly as possible.

"Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away."

- Antoine de Saint-Exupery

People don’t think in the abstract. The major trends in modern software development best practices tend to move from front loading decision making, where all reasoning must by necessity be done in the abstract, to a more agile approach where decisions are made later in the process, when more is known about the concrete outcomes of the previous design decisions. Rapid prototyping encapsulates this wisdom. It’s remarkable how much more focused discussions become and how much easier it is to think about how the software should work when you have a working example in front of you. Starting with a prototype allows you to get comfortable using it and learning the pros and cons, feeling any frustrations with the experience first hand. It’s the difference between having done something, versus having imagined what it would be like to do it.

Software can be difficult to learn, and more often than not is the reason people try an application but don’t adopt it for regular use. There are entire industries built around teaching people to use complex pieces of software. As a general rule you shouldn’t expect your users to enroll in any online courses to learn how to use your application. Luckly, if it’s simple and intuitive, there isn’t any learning curve at all. The simplest software is the easiest to learn, thus launching with a minimal viable product puts up the least impediments to user adoption, and is the most likely to succeed.

That’s not to say fully featured software shouldn’t be built, or that the traditional waterfall approach to software development should never be used. It’s just to say that the best way to build large applications is incrementally, both for the users sake and for the development process. Rapid prototyping follows this approach while encapsulating all the learnings of modern software development. Converting that prototype into a minimum viable product is the best way to launch since the product will represent the fruition of the core idea that inspired the software, will have been used extensively during the prototyping phase, and will reflect the concrete understanding gained from that use. The whole process benefits immensely by having all the stakeholders engaged with it as quickly as possible, and results in the best possible software launched in the least amount of time.