Simplified Requirements
You’ve just finished a mammoth release, satisfied in what you delivered in the time you had to deliver it in, with no time to rest on your laurels you’re back where it all started – Requirements. A good release lives and dies on the quality of its requirements – DEV gets bad requirements, they write bad code, Sales gets bad feature descriptions, they sell nothing or worst do not know what to sell as they can’t understand what the product actually does and sells the wrong thing. Before you start to think this is another one of those requirement posts that tell you what format to put your document in, it’s not. There are some very excellent templates and processes out there that can guide you in creating really good requirements, but a template cannot pull the req from your head and make it understandable to everyone, alas it is only guide to coherent thought.
Right now I am wearing my Product Manager hat, writing requirements, working with DEVs through the design process (and maybe still cranking out some code, be still my beating heart). We have a template that is pretty solid (that I cannot take credit for) but at the end of the day it’s going to boil down to me being able to convey a need to people, getting them to buy into it and organizing the team to build it. To achieve this goal there are 3 things I need to ensure are clear as day in my requirements and regardless of the template you should be doing the same in yours.
What is the problem?
Sounds easy, but some people cannot actually articulate into words what the problem is that that they are trying to solve. It can be easy - we need a checkbox to turn this off - or it can be complex - our competitors are beating us on feature X. In all cases you have to become the problem owner and put yourself in that person's shoes - what is it they are trying to achieve? Where does the deficiency lie? Why are they failing at this? I have seen more often than not where people could not identify the problem and they came up with a resolution that failed at trying to solve it. Take the following example – People are falling off their bikes. Pretty easy right? This is pretty ambiguous and could lead to people trying to solve the problem before they identify it– “put airbags on the handle bars”, “deployable training wheels”, “two rear wheels”, etc, etc. No one ever asked the person with the problem why they fell off – what were you doing? How did it happen? Were you going fast? – at the end of the day, the customer rolled over a small stone and popped the tire and yeah he fell off – all our questions were off, but we inevitably got closer to the solution. So is the problem that he fell off or that the tires are not strong enough to withstand the impact of a small stone? We could do everything in the world to address the symptoms (see above examples) but at the end of the day you’ve missed the cause of the problem.
I read a great blog last week by the guys at Ideative regarding how to be more creative in solving problems. It is a great read and if you haven’t seen it yet check it out here. The best part, that I cannot stress enough, is the education component pre-brainstorming – learn about what you are trying to solve, what have other people done, become familiar with what the customer was trying to achieve – this is an excellent way to approach a problem, come prepared.
Who are you trying to help?
Let's stick with the bike example, whose problem is this? (well its mine as the Product Manager) but who did it originate from? A disgruntled customer, the Sales Team, Customer Support or maybe a local store owner? This is critical information in solving the problem for one HUGE reason – validation and acceptance. Is this going to solve your problem? Different stakeholders have different needs and wants. In our Falling Biker scenario we think fixing the tires is going to stop him from falling off the bike. The customer should be happy with the solution (they stay ON the bike), so should the Sales Team (we're addressing a problem in our design to make the product better), our dealer channel, maybe not - they can't sell extra tires anymore. If you misread who your stakeholders are, you won’t be able to validate whose problem you’re trying to fix. At the end of the day you need to make that distinction.
What will this do for us?
This last one is the question that rarely gets asked as much as it should, possibly because requirements have been fluttering back and forth through multiple iterations doing checks and balances and everyone has bought into the solution at this point –we’re committed. But in reality, it is the most critical part of the requirements process - what benefits are we going to accrue on this? We've licked the problem, the customer is happy with the proposed solution and development is ready to roll... but it’s going to cost $1,000,000. Eh wha? Yeah it’s going to cost that much, and there is no half-way on this solution (it either pops or it doesn’t right). So what now? This example is hypothetical (and I picked the bike example only to illustrate how this can apply to any product requirements) but think about it - if you were to build Feature X to solve Problem Y and it cost Z but you were not going to earn back any kind of benefit (accrued market share, new dealer channels, return on investment) greater then Z, why would you do it? I see requirements with justifications of - "Our competitors do it", "It is missing from our portfolio", "Someone asked for it" - these are all valid but if the follow up questions to these are not - "How much will people use it?", "What do we hope to gain?", “Who are we going after?”, "Is it if of value?", then you're headed for trouble because no one can concretely tell you what the payback is and that is a scary proposition.
At the end of the day, if you're not willing to challenge yourself on the above questions then don't worry about the template you’re using, because you're chances are you’re going to miss your mark. You might build the feature, it might go in smoothly but if no one uses it - you've just added an additional maintenance burden onto yourself, your partners and inevitably your customers. In the case of building software - if feature X is never used, but continually blows up on installation - customers see your install blowing up, not the seldomly used feature, support now has cases to work through on something no one uses and development now needs to maintain a piece of code that is pretty lame. Your maintenance costs just went up and all anyone knows is that the little doohicky on the watchamacallit works great on your new gizmo but no one really wants it because it didn’t solve their problem.