Pain Points - Solve the Right Ones

Nate
Time

I often talk with entrepreneurs about the importance of having a defined project scope. In a SAAS product, it’s important to limit the features list. Early on, I struggled with this in my career because I tried to do too much, too soon. I felt that the more problems I could solve with one solution would increase its permanence or give it greater value. In practice, one small addition to scope opens the door to another. Once the new pathway is developed, it too opens the door to more ideas and additions which in turn, creates a big hairy problem.

The more features I add or change, the later my launch date. Don’t get me wrong: sometimes you have to pivot, but rarely do flashes of inspiration need to be added to an MVP (Minimum Viable Product). Remember, the number one goal is to get data points that show usage and the potential for greater profitability. I can only get data points if people are using my product.

Everything comes back to research. Good research controls a project’s scope. Asking better questions and thinking more critically about the answers is a good formula to get research that is useful. This will save time and money by creating a more solid foundation for the product. A product that will surely be built out with shiny features down the road.

Starting Out: Ask yourself these questions

  1. What will your project accomplish?
  2. What deliverables do you need to see to mark the project as ‘Complete’?
  3. What features are not going to be included in the project and are deemed ‘out of scope’ for this current version?
  4. What resource limitations does the project have including time, money, and manpower?
  5. Are there any dependencies the project assumes will always be available (API’s, prospects, niches, etc.) that you could lose access to?
  6. Most importantly, how much money/opportunity will I lose for every month my project launch date gets delayed?

Managing scope is difficult, especially as more people get involved.

The addition of co-founders, advisors, and investors make sticking to the overall passion like trying to pass a bill through congress with no additional changes. Having the following areas defined will make life much easier as more people get involved.

  1. List all requirements associated with the MVP. To get these, it’s important to understand the customer groups being served by the product. Setting up use cases are beneficial to get requirements.

  2. Define the Project’s Scope. The MVP needs to be made as fast as possible so it can be tested. Sometimes there are features that can wait until a later version to save both time and money. Let’s take the Jeep I drive to work every day as an example. Chrysler offers various Jeep models that include all different types of features. Some features come standard, like seat belts and airbags. Other models come with features like power locks and windows, heated seats, towing packages, moon roofs, and leather. Keep in mind though, that the least expensive, stripped down version can still get me to work in the morning.

  3. Verify the Project’s Scope. Don’t be afraid to show your product to people. Having beta testers lined up is great way to project the initial success or failure of the product. If no one wants to use it for free, then why would they use it when they have to pay for it?

  4. Control Your Scope. Looking back, every time I’ve had to change or modify the scope of a product resulted in me not doing enough homework. There’s no excuse for scope creep. Get it together, man!

The End Goal:

Make something so brilliantly designed and developed that the people using my product will never realize how complicated the technology behind it is.