We have models for trying to ideate what features might be good to include in a product or service. And we’ve got ways to assess idea value. But how often do we really think about the many potential input sources for creating ideas? And what about how we can quickly round out those initial ideas? The following write up assumes that we’re talking about existing products and enhancing them.
We have tools from typical brainstorming sessions to Design Sprints. But again, what about the root sources of ideas? Are there structured ways to try to get to some good ideas? I’m going to offer up a few depictions of idea sources, as well as some ways to quickly assess some early ideas. This latter part, quick initial assessment – or triage, is really the main point. There’s already plenty written about idea development, innovation workshops and the like. But fast assessment is increasingly important. The Minimum Viable Product and Scrum worlds are – at their core – really about trying to sell speed. Yes, yes, I know… the goal is the right product and feature set at speed, but it at least feels over the past decade or so that the desire for speed has been more at the forefront. (In spite of what’s being sold as the product-market fit benefits of the methods.)
Personally, I believe at a fundamental level there’s only two real sources of new product ideas…
- Flash of Insight: This is when you just have that “ah hah” moment. It’s when you’re using some kitchen item and say, “why doesn’t someone make this.” Or a digital product and you think, “you know, if only I had THIS everything would be great.” At that point, you can send an idea into a company, or build your own products if you’re feeling entrepreneurial. But the raw source of your idea was an experience of a visceral need to solve an issue to which you had a solution based response.
- Research: Yes. Of course. Research. Obvious, right? But is it really? There are a lot of different ways to do consumer and marketplace research.
And what about when it’s time to actually craft these ideas into features? We have the modern idea of a Story when we’re using Agile. And there’s a simplistic idea of “What is our Definition of Done” for a story, also referred to as “Acceptance Criteria.” But in some ways, this last bit is really an add on to try to fix the fact that Scrum – for all it’s speedy goodness – may have dropped too much off as it tried to abandon Waterfall methods and heavier product definition documents. Ignoring potential holes doesn’t make them go away. Maybe a bit more needs to be done prior to a sprint planning meeting. While every line item on the lists below doesn’t need to be in the recipe every time, it’s still useful to have a checklist. So I’m going to present some tools for a three phase approach to frame these issues. Here’s the categories and links to the presentations and templates if you don’t feel like wading through the rest of the Step-by-Step explanatory text that follows.
Charts / Sheets Tools for your use…
NOTE: These are meant to be checklists. There are likely too many steps here. You have to edit these down so they apply to your situation.
- Feature Ideation: Sources and Processes
- Feature Round Out (Better Definitions)
- More Formal Feature Prioritization
If you want a little background first, let me take a few moments to go through each of these…
Step One: Feature Ideation: Sources and Processes
When you’re seeking methods to first come up with new ideas, the obvious, “Let’s have a brainstorming session,” thought likely comes to mind. However, just getting together to do this might sound great, but can be so lacking in structure as to be useless. While there’s some who think using formal methods is perhaps too much structure, having some starting places can be useful.
The following presentation offers a depiction of some potential idea sources. How you get at the information is another story. But there’s already tons of easily searchable info on how to drill in to each of these areas with various research methods so I’ll leave that to you.
Link to easier to read larger image on the full Slide: Feature Ideation: Sources and Processes
Step Two: Round Out (Better Definitions)
There’s often a missing step in product feature consideration. And that’s a basic rounding out of a product idea before it becomes a viable candidate for more effort. The challenge here is that we can often come up with a variety of ideas that are amazing, but others that really might not be all that great. It’s easy enough to look at things at a simplistic level and get opinions from around the room. But a fast run through a checklist can also be useful in vetting the idea prior to working hard to fully define it as a backlog item. The idea here isn’t to necessarily do a deep dive on every checklist evaluation item, but rather to at least consider the checklist items rather than just waffle about with little criteria for early idea evaluation.
Here’s a chart you can use as a checklist. You can apply these line items to individual features in another list in some formal step-by-step way, or just blast though the list in a group discussion. Your goal is to determine if an idea is worth further time and effort by yourself and your team. You can certainly do this all by yourself if you want to take an early cut. But usually – as with most things – getting perspective from other stakeholders can be somewhere between useful and “wow, I totally would have missed that.”
Feature Round Out (Better Definitions – Full sheet)
Step Three: More Formal Feature Prioritization
There are many tools and models for determining prioritization. Some are part of an integrated suite including roadmapping and either standalone project management tools or integrations with others, such as Jira and so on. Still, sometimes a simple list and a spreadsheet are the best method for quickly organizing a first cut of things. (And for dumping what can quickly be determined as not having enough value to be worth the effort.) A simple sheet is also good if you’re just not ready to formalize or spend the money on fancier tools just yet. This kind of thing can – and should – be done with multiple stakeholders. For certain levels of cost and time assessment, you mostly likely will need to work closely with counterparts in delivery, development, finance, and perhaps other departments. In any case, the idea here is to run this exercise before ideas even make it into a backlog.
More Formal Feature Prioritization
Conclusion
That’s it! I hope these tools are useful to you. Take, copy and modify as needed for your own use. If you have additions / deletions / changes you think might be useful for everyone, contact me via LinkedIn and let me know what specifically you think should change.