You probably need more data to make your decision

In most software projects that I have been involved in there's always come at least one time during the course of the project where we've hit a crossroads and the right next step isn't clear. Usually there are two or three competing paths that each have merit on their own.

In these situations its typical for people to start relying upon conjecture. The conversation starts to turn from we should to I think.  What's the problem with I think? It means:

• The data the decision is being made on is coming from you and not your users.
• The conversation starts becoming more subjective and less objective.
• There is more risk that you build the wrong thing.

In many situations our experience is going to be enough to make a decision with incomplete information. But you need to be aware when the cost of making decisions based on conjecture can affect the success of the project itself. When there's a lack of data about something that affects the direction of the software using the term I think should be a red flag. Here are three key questions you should ask before proceeding:

If I make the wrong decision, am I able to go back and change it?

If you're building software that others are building on top of then it's likely that their business now relies on the decision you've made. In this case once you've released the software it's going to cost a lot of money and time to go back and change it. If you have a large user base it's even likely that some users will be unwilling to change their use.

What's the cost associated with the decision?

Does your decision require you to make significant purchases in hardware or other software? Do you have to bring on additional people on to the project to complete it? How much additional time will be spent building the proposed solution?

If I build this solution, what am I not able to build?

It's possible that deciding to do X means that you cannot do Y or Z. It's important to understand these trade-offs before you start down a particular path.

So how do you turn the conversation from I think back to a confident we should? Answering those three questions is a good start. But you need to also start the conversation with your users. In agile the product owner is the proxy between you and your users. Product owners are usually in touch with the actual users and can provide a more objective opinion on what your users will really need or want. Bring your product owners up to speed on the context and the ramifications of the decision. Let them help you get the right data to minimize your risk of building the wrong thing.