It’s easy to talk about idea management. It’s much harder to do it in practice. Including everyone in idea generation, in a way that is productive, takes effort. Collecting feedback on each idea can be tedious. But we know involving everyone in idea evaluation leads to better outcomes.
If implemented thoughtfully, you can remove a lot of the barriers, and reap the benefits. Let’s take an in-depth look at how we did both at my last company.
Engaging Everyone in Idea Generation
Within my first month of starting at AfterCollege, I knew I wanted to roll out an idea management solution. Our team was engaged. They cared a lot about the work that we were doing and I wanted to make sure that everyone had an opportunity to be heard.
As I’ve mentioned before, I chose Kindling over the countless other idea management solutions because it didn’t try to be everything to everyone. It did one thing extremely well. It is an easy-to-use idea market solution.
I knew that in order to get everyone in the company to use it, it had to be dead simple. And fortunately, it was. Every single person in our company had their own Kindling account. And every single person used it at one point or another during the time that I was there.
Define Clear Use-Cases For When & How People Should Use It
We didn’t just launch the product and hope people used it. We used it for three different use-cases:
1) We asked everyone to help us reach our goals.
Each quarter we had a product goal that we were aggressively charging after. The product and engineering teams had a plan for how we were going to hit these goals, but we knew we would encounter setbacks and that others in the company may have better ideas.
At the beginning of each quarter, we launched a new campaign in Kindling. A campaign is like issuing a challenge – it’s a way of asking for help generating idea around a particular topic on a fixed timeline.
One quarter, we were trying to increase the percentage of our active users who were trying out our new Explore tool. We asked the entire company to help us generate ideas for how we could do this.
As part of the details of the campaign, we outlined what our goal was, any constraints we wanted people to keep in mind, and the timeline we had for hitting the goal.
We didn’t stop there. Both the product and engineering teams added all of our own ideas to the campaign for how we might hit our goal. This seeded the campaign. Our co-workers weren’t faced with a blank screen. Instead, they could start by browsing our suggestions before coming up with their own. They could comment, extend, or vote for existing ideas, as well as adding their own.
2) We encouraged people to submit any product idea at any time.
What if someone had an idea that wasn’t related to the goal? Was there somewhere to capture that?
Yes. As well as time-bound campaigns, Kindling also supports categories – collections of ideas that are not based on a fixed time period. We had a category for general product ideas.
There were no requirements for this category. They didn’t have to be related to our goals. They didn’t have to be short-term or long-term strategies. This was our spot for capturing any idea as they occurred.
We did encourage people to explain how their idea was consistent with our vision or how it would impact our success metrics. But these weren’t strict requirements. One of my favorite ideas of all time, was one of our coworkers asking for faster internet access – a long time office joke.
3) We collected and prioritized department needs and feedback.
Every product team has to balance building out their product vision with the every day work of supporting the needs of every one else in the company. I’ve never met a product team who wasn’t inundated with internal requests that, if all were addressed, would keep the team from ever evolving their own products.
At AfterCollege, we asked each of our departments to submit their requests through Kindling. Each department had their own category where they were instructed to collect ideas that if implemented would make their lives easier.
For our sales team, their category was populated with incoming feature requests from our customers. For our university relations team, their category was often filled with requests to update the internal tools that they used to do their jobs. For the engineering team, their category was often filled with infrastructure projects that would allow them to build faster, deploy more often, or just make their lives easier.
These categories were extremely useful. They did a few things. First, they made visible to everyone else in the department just how many requests they had. They could compare and contrast each idea and determine which ones were really the most important.
Second, it helped reduce an immediate sense of urgency whenever a need would arise. Countless times a day someone would come up to me and ask for something. My response was always, “We might be able to do that. Please put it in Kindling.” More often than not, their ideas didn’t make it into Kindling for another day or two. It felt urgent at the time, but just by creating a little bit of friction, it turned out it wasn’t so urgent.
This is invaluable and can’t be overstated. It’s not that we didn’t want to support all these request. It’s that it is impossible to do so. As a product team, it’s hard to know which requests are truly important and which just seem urgent to the requester in the moment. Creating a little bit of friction goes a long way toward sorting this out.
Allow Everyone to Vote, Extend and Give Feedback
We allowed everyone to see all the ideas in Kindling. We encouraged people to extend, comment, and vote for each others’ ideas. Kindling makes it easy for people to discuss an idea right there in the product.
My team participated as well. We read each idea, asked questions when clarification was needed, provided feedback, and often helped turn ideas into features we could actually implement.
It didn’t take very long before people got the hang of the system and we had a flood of ideas coming in. We used the voting system to filter the best ideas.
In Kindling, everyone gets 10 votes in each category or campaign, which they can use to promote their favorite ideas or biggest needs. They could choose to stack their votes on a couple of ideas or spread them out giving nods to many ideas. Once an idea was approved – meaning we decided to build it – the votes on that idea were returned to the voter, allowing them to vote for more ideas.
This is a great system. It creates scarcity. There were always a couple of people asking for more votes. Kindling doesn’t allow this and I’m glad. In this case, scarcity is good. It forces people to consider which ideas will help them most (in the case of their department requests) or will help our users and customers most (in the case of our product ideas).
Now you might be worried that if you let people vote for ideas you will have to implement the highest voted ideas. This is not how we used it. Voting was merely a feedback mechanism. The product team still controlled the roadmap and the backlog. However, there were many times where we revisited an idea because so many people liked it. Upon revisiting, we often found merit in ideas we would have otherwise discarded.
Create Transparency and a Sense of Procedural Justice
Last week we talked about being clear about how ideas were selected. The best way to create a sense of procedural justice around idea selection is to be transparent and stick to your process.
For most ideas, we evaluated how it would impact our goal. We estimated the expected impact and made sure it was consistent with our vision. We did this right in Kindling. If an idea didn’t fit with our vision, we explained why. If it lost to a similar idea, we explained why. We wanted to create as much visibility into our product decisions as possible.
People could, and often did, ask questions about or push back on some of our assessments. They argued why we missed something or explained how they saw it differently. Sometimes we missed something and this helped us widen our view of the problem. Other times, it was an opportunity for us to share information about our users or customers with an employee who disagree with our direction.
Communicate and Set Expectations Properly
In Kindling, ideas move through a series of states. When they are first added, they are open for feedback and voting. After they are approved they are closed to voting, and eventually they are completed.
We added some custom states, so that we could better communicate to the whole company where we were at with any given idea. Our ideas went through the following stages:
- Open
- Approved or Declined
- If approved, they then went through:
- On Roadmap
- In Backlog
- In Development
- On Staging
- Completed
When we approved an idea, it was an indication to everyone in the company that we would implement this idea.
We moved it into the “On Roadmap” state when we knew we would complete it in the next calendar quarter and to “In Backlog” when it was scheduled for the next 2-3 weeks.
“In Development” indicated the engineers were currently working on it. When they were done, it was pushed to our internal staging server and the idea moved to “On Staging. This signaled to everyone in the company that it was ready for internal testing.
Finally, when it was released, we changed the state to Completed.
This might sound like a lot of overhead having to move ideas through so many states. But it was quite simple. I spent about 20 minutes a week, updating the system every Friday afternoon.
If you consider how much time you spend updating everyone in the organization with what is coming when, this is a huge time-savings. It provided 100% transparency into what we were working on, what was released, and what was in the pipeline. It was well worth the time.
I can’t imagine not using Kindling to collect and evaluate ideas. It helped our product and engineering team provide transparency and engage everyone in the company around what we were building.