Step One: Establish a shared understanding – who is involved?
If there are existing customers that are interviewed – have a member of the front end interface team and someone from development there to hear the concerns directly. The way a customer talks about issues will mean different things to different team members and those intersections will elucidate other issues and features. If there are no customers just yet – always have members of the front end and back end team there to talk things through. It should be no surprise that features have implications on each other – in front end, back end and maintenance contexts. The more team-oriented you can make your product requirements process the more successful your product will be. It may feel more than painful at times, having all those different minds wrestling over the breakroom table, but it’s better they do it than your user’s walkout in frustration over something you could have foreseen.
Paul Heltzel has a good article on building good teams –it’s worth reading and taking notes and taking action too.
Step Two: Who is your user, your market?
It’s an unavoidable truth – you have to decide WHO is going to spend their time on your system, wrestling with your product, making it part of their life. You need to be clear about who they are from a sales and marketing perspective, but another reason is knowing WHO exactly cares about your sexy bells and whistles and who doesn’t at all. You can have multiple user types, and should. Some can be primary and others secondary but getting tight about defining them give you someone to imagine saying, “What? Why? Why would I use that?” or “That’s nice and all, but what I really care about is X.” I can tell you from personal experience – this is worth its fictional weight in gold. If you don’t do and just follow your nose building what customers demand, adding features because someone is willing to pay, letting developers add willy-nilly; you’ll end up with a cumbersome product that difficult to maintain, configure and sell! And that is not the point of this exercise. The addressable market article is one place to start, as is this, this and this.
Step Three: Pain and Goals.
You’ve heard this regarding sales and marketing too – but it applies to product features too. Spending time and energy on your product is a form of payment. Their pain is what keeps them up at night – their goal is to solve that with your feature. Align all features directly or indirectly with their pain. Not everything has to be the reason they come – some features can be for delight and convenience and certainly for clarity and necessity but make sure you’ve addressed their pain before you add bells and whistles. A primer for the benefit vs features can be read here. A good matrix that considers pain and features is worth exploring here.
Step Four: goals and business objectives.
Having an understanding of the business objectives of your users is important. That’s part of understanding their pain. No one buys a service you offer. People buy a solution to their pain – regarding their pain. If you don’t know this yet, you’ve missed a lot. If you know this but still somehow act around “what you do” vs. the pain of your buyer – then you aren’t alone. Their objectives are important – it keeps you honest. Your business objectives and goals are also important. You want to build a good product that’s easy to manage and sell. You want to build it for a market that can afford to pay for it and needs it – moreover a market that knows it needs your products. These all seem pretty basic, but you’d be amazed at how few start-ups and restarts never ask themselves thee questions. Never. A good exploration of business objectives and how they might control scope is worth your time here.
Step Five: Background and strategic fit.
Strategic fit – also speaks to the user and your internals. Is this service or product a good fit for the user strategically – either because it’s so dang useful it fulfills a basic need? Does it fit your strategic objectives? Are you a company that wants to stay small, lean and profitable? Did you run the numbers around supporting this? Did you investigate, in a credible manner, the target market? Are you aware of the cost of support? Implementation? Configuration? Training? How realistic are your numbers when you try to explain them to an investor or another entrepreneur? Get granular; why are we building this feature? What is the user getting out of this improvement as opposed to the other? How does that fit into the overall company objectives? Here’s a good 3-step product-market fit article to help with this stuff.
Step Six: Keep track of your assumptions.
List the technical, business, or user assumptions you might be making. Get deep here. Assumptions can be illusive you need to be radically honest here and maybe even don the cape of Captain Obvious. “We are assuming people can read” or “have email” or “won’t be accessing the service on their phones” all have deep implications – keep track of these things, revisit them throughout the development process.
Step Seven: Develop some useR stories.
This isn’t everyone’s favorite step but without a clear idea of exactly what someone will do once they sign up/buy/commit … you are just setting yourself for a world of hurt. Don’t write user stories that aren’t user stories but a description of all features – instead, write a story that talks about how Jane signs up and gets X and then does Y and then pushes this button and fills this out and looks for this bell and responds to that. Detail what Jane wants to see, how Jane is going to do this critical thing or that critical thing. You may need to write out 4 or 5 paths that Jane takes don’t get too complicated trying to draw one big picture of Jane’s entire experience just persist down the path. By doing this, you’ll uncover a lot of questions that need to be clarified, natural features, not to mention real clarity around what Jane wants to do. When you are done with your user stories focused on the people you are selling to – write a few more for the people that are going to maintain the application, administer user accounts and the people who will need to support the entire operation. These user stories will go a long way to filling in the gaps in the interface that you won’t necessarily have thought of. Tips about good user stories can be found here. Examples can be found here.
Step Eight: Keep track of the questions.
As you go through this process there will be more questions than answers. You don’t have to answer all of them in order – just keep a running list and visit the list often. You may find a moment of clarity that puts a handful of them to rest – there may be some that need to be fussed over for the life of the build process. There’s nothing worse that having a question, forgetting what it was, and having it come back to bite you. Not all questions are complicated, but the answers usually have implications and where there are implications there are divisions in a team. Create a table of “things we need to decide or research” to track these items.
Step Nine: What we’re not doing:
There is what you are building and just as important is what you are NOT building. As this process evolves keep careful notes of what you are clear about NOT doing; whether because it’s not in scope now or never will be. Know, and accept, that members of the team will come and go, having clarity in writing will help keep understanding consistent throughout an evolving team.