Whenever a new project starts, we do a few standard things:
– Identify the general product / idea
– Identify several classes of users it appeals to
– Draft Use Case Scenarios for each user class
If, for example, your project is a “game”:
– you might identify the general idea as a game played on a court where two teams each try to sink a ball into a basket;
– the user classes would be children, competitive sports – high school, college, professional , casual adults;
– a use case scenario might be an adult goes to a gym to work out and sees 5 other friends who want to play a game together.
Use cases can really help help you focus on specific product features — figuring out what have the greatest utility, broadest appeal, or largest differentiators against competitive goods and services. They’re often created both during team brainstorming sessions and as homework for the various client ‘stakeholders’ in a project. These stakeholders who best represent the end-consumers should create at least 1/3 of the Use Cases, and should sign-off on all of them. In a startup/corporate environment, that would mean the Product Manager and perhaps some C-Level executives; in an agency environment that would mean the Client and their team, not the internal strategist or team. Why? Because when the stakeholders drive the Use Case creation, you have better insight into the core business goals, market opportunity, and targeted user demographics.
Like everything else in your project, your Use Cases will shift with time as your product matures and you get a better idea of who your actual audience is — so you’ll always have to revisit them to update and add new scenarios. Despite this changing nature, it is unbelievably important to really think things through and create detailed use cases. In the past year alone, I’ve been part of three projects that all became seriously derailed and stressed because of bad Use Case Scenarios on the same exact product feature — the “Search” function — so I’ll use that as a paradigm.
In every situation, the original use cases described something very simple, like:
– I type in /chocolate/ and it shows me a list of recipes that match chocolate. like in the title.”
But then they progressed as the stakeholders used the first version:
– When I type in /chocolate/ it should show me a list of recipes that have chocolate in the title, or as an ingredient.”
And then they progress a little more:
– There is chocolate in the description of this item , and it’s not showing up in search. I meant for the description to be part of it too.”
And then…:
– “Someone commented and said this recipe could be good with chocolate, that should be in the search results. But it should go later in the results.”
Oh no:
– “Wait a second… why am I not seeing chefs/authors who write about chocolate. they’re most certainly relevant.”
And then, overload…:
– “This kinda works. But I should be able to narrow these results down, like in Yahoo or Google. And we should show more info from the recipe in here. What about a picture ? And misspellings / near spellings ? It should detect those. People spell certain ingredients differently. We have a lot of Europeans searching, how will é ç and other characters match in search or recipes ? This seems to be broken. It is broken. This sucks, you’re wasting my time and money.”
To the stakeholder , there is no difference between these requests — they specified a search function, and they expected it to work a certain way; the product team failed at each interval to deliver on their expectations. To the stakeholder, the search function is a “black box” — they don’t know and don’t care if the mechanics behind each iteration are different… it’s a search box!
To the product team though, each iteration was a completely different product and each one required vastly different amounts of resources.
The first iteration — searching on the title — was a simple and straightforward search on a single field… and described as such, a team would just search directly on the database. The resources allocated to this would be minimal – it’s literally a few lines of code to implement.
As the search use case gets refined, the product design moves from searching on a single field to searching on multiple fields — probably using joins and views — and calculating search results. By the end of the product refinement, its quite clear that a simple in-house search solution can’t deliver the experience or results the stakeholder actually wants, so we need to look into other solutions like Solr/Lucene , Sphinx or Xapian. These advanced options aren’t terribly difficult to implement — but they go beyond a single search function into running and maintaining separate search servers , configuring the engines, creating services to index documents, creating resultset rules for sorting, creating error-handlers for when the search system is down, etc etc etc. The simple “Search” button grew from a few lines of code into a considerable undertaking that requires dedicated people, days of work, and a constant tailoring of the resultset rules.
Eventually the product teams will scream “Feature Creep!” and a manager will flatly say “Out of Scope.” Items like this are unfortunately both — but they shouldn’t be. The intent and expectations of the stakeholder have rarely changed in this process, they just failed to articulate their wants and expectations. The blame, however, is shared: the client should have better described their needs; the product manager should have asked better questions and better managed the stakeholders “Use Case homework”.
With a properly written out Use Case Scenario — in which the stakeholder actually illustrates the experience they expect — the product team is likely recommended the latter scenario, and offer tiered suggestions leading up to the desired expectations with the resources/costs at each point.
Unfortunately the status quo is for stakeholders to half-ass the Use Case. Few product or project managers will pick up on the shortcoming , and the tech team will never pick up on it. So “Search” — and any other feature — gets reduced to a line item with little description or functional specification, and when development beings it becomes built in the easiest / simplest way to satisfy that request. This predictably and unilaterally results in expectations being failed and the project getting derailed. Not only are the simplest and most robust solutions to “search” built, but every single step in between — costing dollars and immeasurable team spirit and energy.
The old adage about medication — An ounce of prevention is worth a pound of cure — holds extremely well as a truth about product development. Articulating exactly what you want and need to accomplish before development begins will save dollars and countess hours of stress.