There is one universal truth we’ve uncovered while working with customers over the last four years: everyone is busy. Toy companies, federal agencies and financial services firms; CEOs, Product Managers, new hires; salespeople in the field and marketing staff in the home office. Everyone is busy.
In addition to serving busy people, Kindling competes with a host of other systems vying for attention. This includes internal blogs, CMS systems, intranets and the undisputed king of attention: email.
We design Kindling with these constraints in mind and embrace the fact that our users are busy. We use this to drive not only which features we choose to build, but how we design those selected. We believe that an effective innovation management product must help users navigate the sea of content created by the community, else it just becomes another part of the problem.
Signal to Noise.
Imagine yourself a user of an innovation management product in an organization with 4,000 participants. A fair average is that each user has two ideas and six comments per quarter – that’s 32,000 units of content. If you were to log in to the system every few weeks, there may be a few thousand ideas and comments waiting for you! Of those, plenty are noise, but a few are gems. And without your input, they may never realize their full potential.
But of course, you’re super busy… you have a presentation tomorrow and are getting ready for a vacation. Oh, and you have to finish your team’s reviews.
Where to start? You could search, follow an interesting tag or you could just start reading the stream. But with each of these approaches, you’re relying on a bit of luck for finding a relevant idea. And luck doesn’t scale.
When someone signs into Kindling, they aren’t immediately confronted by hundreds of ideas and thousands of comments. Kindling presents them with exactly five ideas, selected to match to their interests. A Kindling user that only has five minutes? No problem, they can start with these ideas selected specifically for them and read through more recommendations, time permitting.
Well-designed Products Listen.
When designing Kindling’s recommendation engine, we looked to the market for inspiration. Typically, recommendation engines work their magic using a mix of data explicitly provided by the user, and information inferred by usage of the product. Below are examples of explicit and behavioral feeders to recommendation engines.
Explicit actions that drive recommendations:
- Telling Netflix that you liked Chinatown but didn’t especially like Adventures in Babysitting.
- Indicating to Amazon that you like Science Fiction but don’t enjoy Documentaries.
- Letting Hunch know that you like Kidrobot and skateboarding.
- When you finish reading an article about Silicon Valley in the iPad newsreader Zite, indicating that you liked the article, author, and the tag “startups”.
Implicit behaviors that drive recommendations:
- Which search results you click on in Google, the words you use in GMail and the content you post to Google+. Google of course, being masters of leveraging your implicit behaviors to inform a profile of you as a person.
- The traits and qualities of the people you interact with on OK Cupid and, as importantly, those you choose to not interact with. Every click in OK Cupid informs their understanding of you. They’re listening.
- What items you search for, visit and purchase on Amazon.
- The songs you listen to on Rdio, and the listening history of those in your network.
As demonstrated by Google, Amazon, OK Cupid and Rdio, truly thoughtful software listens. Hidden in a user’s interactions are clues. For Kindling, these clues are everywhere: a user that works at a bike company recently searched for the words “frame”, “weight” and “design”, they’ve turned down notifications for marketing-related ideas and have repeatedly shared ideas about frames with their coworkers. It’s pretty easy, if you pay attention, to see these patterns and insights.
This is exactly the approach we’ve taken with Kindling – we’ve built the recommendation engine to use any explicit data offered by the user (but remember our constraint – people are busy, so they’re usually too busy to tell Kindling about their likes and dislikes) and to pay attention to all of the user’s actions and behaviors. The combination of these allows us to draw a good picture of each user’s interests and use this knowledge to recommend relevant ideas.
Positive Feedback Loop.
Application designers often fall into the trap of assuming that because they want their user to tell them something or interact with data in some way, if they put a button on the UI, it will be clicked. But users only click buttons that help them; they have exactly no interest in helping the design or development team.
This law of product design led us to my favorite feature in Kindling – where the product informs the user exactly why a particular idea was recommended. This allows the user to quickly correct our assumptions – they may have searched for “marketing” for their boss, or perhaps they’ve changed roles and are no longer interested in “HR”. Now you might be thinking: why would a busy user spend five seconds to click this? Aren’t they too busy? Yes! But they trust Kindling’s recommendations and want to make them better. A five second investment in receiving better recommendations in the future. Their goal, not ours.
Kindling’s recommendation engine is one example of a feature born out of understanding users’ constraints and being thoughtful about product design. If you’d like to learn more about this feature or the rest of Kindling, contact us for a tour of the product.


Leave a Comment