You've probably seen this adorable image already and if it won't convince you, nothing will. So we'll start from an assumption that you're trying to make something lovable. But what does that really mean? I'm trying to release a large new feature for my product. I want to get it into beta as quickly as possible. Do I ship what we have? Does it need "just-one-more-thing?" 4 more things? 10? There are 18 important features I can think of off the top of my head that it doesn't have. Which ones do we build before Beta? What is the minimum lovable product?

Oh and I'm on a team with 5 other extremely talented and opinionated people who've sat in on the same user tests of the Alpha as well. They probably have some opinions too... So what do we do? And how do we avoid a 3 hour planning meeting?

Here's how to decide what features to build:

1. Get all the options on the table. 
2. Have everyone think hard about the problem by themselves.
3. Have everyone propose a prioritized plan of action. We need everyone to wrestle with the trade-offs and put a stick in the ground, because it's only by wrestling with these choices ourselves and seeing that there's no one right answer that we will be able to accept a final plan that we may not entirely agree with.
4. Compare the results. Analyze outlier opinions. Look for agreement.
5. Put together a plan. (Together if possible, or just have Directly Responsible Individual do it)

Let's see what this process looks like if we use ForceRank to coordinate. First we'll build a questions and define a list of choices. In this case it's all the possible features we could build. We also add a "Release Beta" choice and tell people to prioritize it at the point where they think we should release.

Then we just send an email to our colleague and they can jump right in and start ranking the choices.

Success! Now we have responses from my 5 colleagues. You can see the overall preferences of the group on the right. The results are colored so that we can easily see outliers. It looks like Mike and I generally agree. But you can see that when I hover over the second choice on Mike's list I actually ranked it much much lower. Sounds like we should discuss that one.

Mike and I generally agreed, but if we compare my opinions to Chase's we can see that there are some real differences. Indeed the groups 17th priority was something Chase thought should be #4! Since Chase is the UX expert, it sounds like perhaps the engineers need to understand why we're rating those things on the bottom.

Finally we can also compare everyone's results against the overall scores as calculated by our algorithm.

I hope this has given you a good idea for how to systematize the discussions you have around feature development for your product. The goal is to have smarter, better, faster discussions. Using a system like this you'll find you don't even need to discuss some options because they're either unanimously important or unimportant. On the flip side, the major disconnects in your group will, quite literally, glow red and allow you to focus in directly on what matters.

Happy Product Releasing to You!

It all started one day when we tried to count the votes.

So you know how ForceRank.it works right? Your group ranks all the choices, then we add up how many points each choice gets and boom, we show which choice is the most popular.

Right?

Well, it turns out that this is one of those cases where "the obvious way" can produce very unintuitive (and hence arguably "wrong") results.

How is that possible?

Let's see an example. This is a poll that one of our users created to figure out what topic should be the subject of his tech talk. Give it a quick look and you'll see that three out of four people had the same first choice. So picking a winner should be easy right?

But that's not what happened. 

The first version of our algorithm picked "Mapreduce and KIR" as the winner. How is that possible you ask? Well, let's do the math together and add up how many points each option should get. I'll highlight just those options below.

So with 9 options each, "Mapreduce and KIR" gets: 9 points from Matt, 7 from Jessica, 8 from James and 6 from Greg, totalling 30.

And Newbie HBase gets: 1 from Matt, 9 from Jessica, 9 from James and 9 from Greg, totalling 28.

Hrrmph

We dubbed this the "Matt Ball" effect, but the more canonical description is that our algorithm has failed the "Majority Criterion", which states: "if one candidate is preferred by a majority (more than 50%) of voters, then that candidate must win".

So what did we do?

Well, we went to the wikipedia and dug into Voting Systems. Unsurprisingly it turns out that there's been a lot of high quality thinking on this subject. We looked into a number of methods and the one that seems like it is the best fit for ForceRank was Schulze Method. In a nutshell, Schulze breaks down the voting into a ton of mini ranking between each combination of options, what they call a "pairwise-analysis". Next it does a neat bit of graph magic to pull out a series of winners.

The result, is that it is guaranteed to ace the "Majority Criterion" (which our previous method failed) and a number of other conditions as well.

The only real downside is that Schulze method is a bit more difficult to explain, but at the end of the day it delivers an answer that feels much more intuitively like the "fair" winner of a vote.

Next Up?

Next on our list is building in ways to see the patterns in your group's rankings. There's a lot of really interesting information to be gleaned from the data that ForceRank provides and it's our goal to help you get a quick and easy to comprehend understanding of the complex nature of your groups preferences, and the outliers within.