3 Questions to Ask Before You Begin Development
Before you start writing a requirements document it is important to ensure that you, your team, and your business are ready to start development. A requirements document is much more than a set of specifications, it should outline your product from all relevant angles and explain how the end product will work with your company as a whole.
I have seen hundreds of requirements documents and I put together a quick list of three questions that need to be answered in order to avoid some of the most common pitfalls in product development. By answering these questions your chances for success will increase and you will have a clear plan to move forward.

What problem am I solving and for whom?
You should have a clear, concise, and articulate statement about what the problem your product will solve. This will help you decide what your product truly needs to be and will eliminate a lot of unnecessary features that may not add any value.
Here is a great example: American mothers have so many jobs to do that time intensive work is put off and becomes time sensitive after it doesn’t get done!
Your problem statement shouldn’t speak of the solution yet, it should just simply state the problem at hand. If you showed the problem to your target customer, nearly all of them should beg you to solve it. If this isn’t the case you either don’t have a real problem at hand or you haven’t honed in on your target enough. Before writing a requirements document, talk to the people you are building for and understand the problem from their perspective. Do they need a solution and how badly?
Your product is not, nor ever will be for everyone! Think of the diversity that exists in the world:
- Cultural
- Geographical
- Linguistic
- Occupational
- Age
- Gender
- Psychographic
- And so much more!
What specific group or groups are you building for. Who needs you product the most? These are the people you should build for.
Do I have a clear product?
Many companies that write a requirements document end up describing a vision or a problem, and not a solution. This is indicative of the most common problem I see with many requirements documents, the writer doesn’t have a full understanding of what of the product is. Such a document will describe on a high level what the product is, without getting into any details about how the solution needs to be implemented.
Here is a prime example of a description written by somebody who clearly needs help writing the requirements:
We are building a two sided platform that will allow qualified homebuyers to view properties on their own time without a broker present. Homebuyers will be able to use chat, browse listings, and schedule appointments all within a mobile app. We will use an IOT device to secure the home that will need to communicate with the app and unlock when a qualified homebuyer approaches the door. Our revenue model is to target ads to the new homeowners and also partner with lenders to help the prospective homeowners find financing.
Reading this, I see that the writer has a vision for what the business will ultimately look like, however, I have nowhere near enough information to understand the product. There are major holes which are left unexplained.
- How are homeowners qualified?
- What is the security risk?
- Who are they chatting with?
- How will all of the data needed get into the system (real estate listings)
- What are the technical specs of the IOT device, how does it work?
- What kind of ads, how are they implemented?
- What kind of admin functionality is needed?
- How many users will be in the system?
- And so much more
To me I could envision this system being built for anything from the low five figures to a multiple million dollar enterprise deployment,and I have no indication what the client expects!
It’s okay to not know how exactly your product will be built, and I would say that many people who do write requirements documents actually aren’t qualified to write them. (Great Example Here.)
But that’s why software development firms exist! You come to a firm with a problem or idea, and after some consulting work you have a full understanding and true breakdown of what your product is — which leaves nothing to the imagination. The more detail and clarity there is, the fewer assumptions need to be made.
At JINN we recognized this and the majority of our clients go through a full Design Phase before a single line of code is written.
What is my plan to Launch and Grow my Product?
Just because you build it does not mean they will come. Here are some thought provoking questions that you should consider. These answers should change as your learn more over time, but the earlier you have a plan for them, the less of a burden they will be later on.
- How will my product get users?
- How will the users be trained on how to use the product?
- How many users does product need to service?
- What assumptions do I have?
- What kind of testing is needed before launch?
- How will customer support work?
- What will my financials look like?
- What milestones are planned in the long run?
- How will my product reach those milestones?
- What kind of funding is needed?
- What kind of team will my product need?
- How do I ensure my product runs smoothly if I’m not around?
Summary
Great products are not built in a day. You will not suddenly come up with a multi-million dollar idea that will change the world. Sure you may identify a problem and have a vision for how it may be solved, however, to truly build and execute on your vision requires the input of a number of people, many iterations, and lots of hard work. I hear great ideas every day, I seldom see great execution.

