Software development is about answering questions. Answer the right ones and you have a viable, useful, well-thought of product. Answer the wrong ones... well, we've all see that software at work. Based on my experience working with software teams, here is the series of questions I believe keep us on the path to successful product launches.
The big up front question of course is What is the business problem we need to solve? Ensuring a good answer to this question is our first critical step.
Be it provide an easy, yet secure way of getting cash when you want it, or reduce pricing errors, or tell me where to find the nearest Starbucks, we need this overarching goal to focus and guide our journey ahead. I have often found it useful to start with that answer and break it down into more specific goals that the solution team can solve. In the Scrum world that is what the product backlog is all about and the picture below describes the process of getting to "bite-size" chunks of the problem that the team can address sprint after sprint. What is the business problem? What business scenarios comprise that problem? Who is going to use our product to address this problem? What special needs or constraints do they have? What are the intermediate steps? What actions will our users take to reach them? We should not start building software if we do not have good answers to these questions.
Minimum Solution
Once we have the business problem answers in hand, then we can move on to the next series of questions. Are we building the right solution? What is the least amount of work we can do to allow our business sponsor to see enough of the end-to-end solution he envisions so he can validate the solution actually does what he needs it to do? I call this the Minimum Solution. It is not every scenario. It is not every variant path. It is not every combination of conditions. It is the basic structure of the solution that gives our business partner a sufficient level of comfort that we are on the right track to solving his problem. Coupled with that need, is the need the solution team to answer Do we know how to build it? Are there technology puzzles we need to figure out? Are there technical unknowns that could become show stoppers? Once we have adequately done this, there are still more questions for us to address, but we can now be reasonably confident that they will refine our effort, not derail it.
Minimum Marketable Feature Set
Building on the minimum solution, What must our users have in order to see value in our product? It is not the full product. It is the first step of things to come. -- I can now get cash when I want. At some later date, I'll be able to make a deposit too. -- Now I'm charging the prices I intend to, at some later date I'll also be able to analyze if I have an effective pricing strategy. Our organization has a stake in this as well. What needs must be met to support our own interests? It might include a certain level of security, or the ability to get feedback. Whatever those needs are, we must be sure the Minimum Marketable Feature Set meets then as well. Ever notice when a new high-rise is built, the lower floors are occupied and generating revenue while the upper floors are still being completed? That is the Minimum Marketable Feature Set concept at work. It provides value early, allows us to see that we built the right thing, and helps us understand what should come next.
Fully Featured
This is the full product. Has the original business problem been solved? Have all of our users needs been met? Can they effectively use the product to do their jobs? Has the product made them more effective in doing that job? Have all of the organization's needs been met? Reaching this point may actually take several releases of the product, each adding some new area of capability to the Minimum Marketable Feature Set. One cautionary question should come to us as well. Is this a new business problem to solve? along with Is this the right product to solve that problem, or Should we build a new product? Should our toasters really bake bread too, or should we build a separate product to do that? We need effective product management to keep answering these questions throughout the life of the product, not just through the first release.
Gold Plated
Several questions come to mind here, but the real one is Our product is out there in the real world, our users love it, why are we still writing software? We often find it enticing to continue tinkering, but we should be cautious. Adding new features to a successful product, does not automatically make it more successful. We should be asking Have we gone too far? To what purpose will this feature being used? Is this a cool piece of technology in search of a business purpose? Are we adding "flash" to the product just to get better noticed? When to stop it a critical decision point and we must learn to recognize when we have reached it. Then we are free to move on to the next great product idea.
Are you answering the right questions about your software development?
Step back for a moment and consider it. You may be surprised by how much more effective you can make your development efforts, and how much better your products are as a result.
