SQL for calculating Churn, Retention & Re-Engagement

Posted by Jeff Dwyer

Feb 22, 2015 10:32:00 PM

Churn rate. It's probably the most important usage number you could have, but boy is it a pain in the butt to calculate. Or is it?

For ForceRank.it we don't have a ton of traffic so we've still got a simple table of events, where event is something like "login" or "pageview". Whatever your database though I think it's likely you have a table that can function like the following:

So what are the steps we need to do to calculate monthly churn?

1) Figure out how many people used the application each month.
2) For each month, figure out how many of those people did or didn't use it the next month.

So step 1 is trivial, right?
That was easy... but now we're in trouble. We've got the number of active users, but we've lost who they were, so now we can't compare to the next month.

At this point it's easy to end up trying
  1. Join the table to itself, which is described here but this can get impossibly slow as they explain here.
  2. Say to hell with it and solve for one month at a time and put that in a cron job, and save it to a new table.


The Problem with Cron

The cron job works, but the sad thing about it is that now we've got a table of churn numbers, but we're locked in and can no longer segment. How do paid users retain vs free users?  Sorry, you're going to need to refactor this whole solution.

Enter Window Functions

So is there any way to do this in one fell sql-swoop? The good news is that there is, brought to you by window functions and lag() lead() functions in particular. .

Lag & Lead mean that we can iterate over results, comparing our current row to the next row. This is huge, particularly because we can partition by user. Lag and lead are available to you if you're using PostgreSQL, Redshift, or pretty much anything except MySQL

Let's see what this means in practice.

1) Who used it and what month they used it. To make things easier on ourselves later, lets represent the month as "number of months since 1970" so that we have a simple monotonically, increasing number.

logins by month

2) For each row in #1, what is the next and previous month they used it, partitioned by user.

logins by month compared to lead and lag

Ooooo!!!! Now we're getting somewhere!

3) For the results in 2, what's the difference between our current month and the next month. If it's one, then we know that the user came back the next month. If it's two or more, then we know there's a gap! That's a churn!

This table has everything we need to know!

4) Case statement the various possibilities. As an extra, we now have great insight into whether we are getting "revived" or "return" users.

5) There's some final cleanup and UNION of the two different data sets before we're done. You can see this in the complete query below. Basically we sometimes have >1 important row (ie the churn and the active) per row, so we double query our calculated table and union the results. But voila! We've got a single query for churn/active/return/new users.

Final Results after a quick Excel import and Pivot Table:


In summary, the above sql is a super useful way to get user activity data out of your database. Because it's a one stop query, it's really easy to add additionally filtering or grouping to this query, meaning you can easily segment these results.

ps   Performance 

Oh right, and how does it perform?  Well on Redshift anyway cranking through 60Million rows takes about 7 seconds. In PostgreSQL I've haven't tried it on anything that large but it's never given me a problem.


Curious about what we do here at ForceRank? Give it a try!

Try ForceRank Free


Topics: Tech, sql

Prioritze Your Trello Backlog

Posted by Jeff Dwyer

Jul 14, 2014 12:29:00 PM

The only problem with Trello is... 

Trello is one of my favorite tools on the web. So many other collaboration tools turn the very act of putting together a TODO list into something that feels like filling out your TPS Reports, but Trello feels so lightweight that is is often "just-enough-process" for even a large product development team.

The only problem is that it's so easy to add items that it's easy to end up with a "Backlog" list that goes from 5, to 10, to 25 items and eventually it turns into a total junk drawer.


One solution is to nuke the list from orbit, but that can be overkill and it's sure scary to nuke a list with that includes cryptic cards like "fix issue with missing data" or "fix security". Still, something needs to be done to separate the wheat from the chaff. What we need is a really quick way for people on the team to share their opinions about which cards are most important.

New Trello API Integration

I'm super pumped to show you ForceRank's new Trello import. With one quick click you can turn a big list of cards into a rankable list, upon which the team can quickly vote. Once that's complete, BOOM! You've got the wheat on one side and the chaff down at the bottom. Let's check it out in action!

Step 1: Find a List You'd Like to Prioritize


Step 2: Create a New Question in ForceRank

A free account will work just fine. Then you just click "Import from Trello".


Step 3: Select the Board and List

Trello will ask you to authorize ForceRank and then ForceRank will show you a list of all your Boards and Lists.


Step 4: Name Your Question


Step 5: Drag and Drop to Prioritize


Step 6: Share and Compare

Then just share the link with your team and they can easily vote as well. Once you've voted, you can compare the overall results and dig deeper into any disagreements with the comarison tool.


That's it! I hope you'll give it a try and let me know whether this is useful for you. For other ideas about how to use ForceRank for product management check out But What Is The Minimum Viable Product.

Happy Trello-Taming!

Try ForceRank Free





Topics: Tech, Product Design

Post Natal Part 5: Homepage Design Iteration Examples

Posted by Jeff Dwyer

Jul 14, 2014 12:28:00 PM

This is part of our "Post-Natal" series on the development of ForceRank.it see Building ForceRank.it for the rest of the series.

So I'm sure we can all agree that the homepage is pretty important. It's the one thing people are guaranteed to see. It needs to load fast and then you've probably got 1.7 seconds to tell people what you're about.

Oh and most people don't read the words.

If you haven't already read it, How I increased conversion 2.4x with better copywriting is Amy Hoy's fabulous how-to on homepage design and I totally subscribe to her philosophy. My takeaway from her piece is that the homepage should tell a very clear, quick, focussed story. Do NOT start with features. Start with the problem. Dive deep on the problem. If readers can tell that you understand their pain, they'll give it a go even if they don't understand your solution. If they just see features & pricing and a testimonial you make them do all the hard work of figuring out whether this solution is right for them.

So with that in mind, let's see what we actually came up with. (You'll see a big Hoy-style rewrite about 4 revisions down).

Iteration 1: Too focussed on the product

This was close to placeholder, but it's worth looking at to see where we started. I did a lot of hand-wringing about the difference between "Decision Tool" and "Opinion Comparison". You'll see that I flop back and forth between "Simple Group Opinion Comparison" and "Group Decision Making" throughout these iterations. The reason is that I HATE the idea that a tool would make a decision for you. That's just a horrible idea. ForceRank is supposed to improve communication. But that sounds a little wishy washy and "Decision Making Tool" is about 300% easier to read than "Opinion Comparison Tool".

The second theme in here is explaining the "Force" part of ForceRank.it. ForceRank is unfortunatey a word with a very unhelpful connotation to Jack Welch's Vitality Ranking which is a way to rank employees reward the top 20% and then cut the bottom 10%. I wanted to make it clear that that's not what we're doing here because I think the demand that things be ranked is a great feature of ForceRank.it Since you can't have two #1 priorities you are forced to make hard choices. The bonus of making these hard choices is that I think it makes you more empathetic towards the eventual decision maker. Too often I see situations where each stakeholder wants their project #1 and has no sympathy for the eventual decision. 





Iteration 2: Make it interactive

This was a great idea that I got from Maggie Steciuk. She just kind of mentioned it in passing but I really liked the idea of letting the user actually play with the thing without signing-up.

Part of this stems from the fact that we have an enormous onboarding challenge. Rarely are people walking around wishing for just exactly the kind of solution that you've created. But this leads to a real difficulty when getting people started. In every user test I did, I got huge positive feedback about the idea. People were really jazzed about the potential and said they absolutely felt the pain I was describing. But then when they land on the "Create your first question page" everything grinds to a halt. What problem should they do first? Hmm. What are the possible choices? Those aren't easy questions and that's fine, but it also means that task #1 is a serious time commitment from your user and that's not great.

The idea with interactive homepage is to give people a bit of the payoff/reward of ranking and comparing results with a dummy set of data. The user tests I did of this were positive. People seemed to have a much better sense of what the product could do for them. That said, it definitely didn't fully solve the issue of bootstrapping them.


Iteration 3: Personas

I think one of the best things about ForceRank is that it can help even out the playing field between introverts and extroverts, people that dominate meetings and people that prefer email. Hopefully the tool can provide a way for introverts to contribute ahead of time, while providing a great jumping off point for the meeting itself. I write a bit more about this in The Personality Zoo: Meeting Zoology.

As part of that I wanted to give people personas to resonate with, so we made some nice personas.


 Iteration 4: Cave in and call it Decisions

As mentioned above you can see here that I've axed the confusing "Group Opinion Comparison" wording. Starting to get a bit Amy Hoy-ish. Do you see anything about what the product "does"? No, you don't. Describing the pain.

Also Mike convinced me that the picture of my couch was lame.



Iteration 5: The Full Amy Hoy

Allright, this is my pass at a full "describe the problem" long form homepage. I get a little crazy with icons. And I go on a bit of a rant about how this is not groupthink. I'm trying to avoid the "This Tool Will Make Your Decision.

Also I brought the couch back because I have no taste.


 Iteration 6: Simplify. Simplify. Simplify.

 Watching users read the previous page it was obvious that they didn't, well, read the previous page. This iteration relies heavily on the idea that the interactive parts of the tool are going to show exactly what we're doing. And it hopes, (possibly incorrectly) that the quick hits on top are enough to describe the problem.

Also more CTAs and I finally decided that couch needed to go.




Iteration 7: Long Form

I wrote a blog post But What Is The Minimum Viable Product? which was pretty popular so I had some much better screenshots of use cases. I've always liked long-form pages as well. They seem like they do little harm for people that are ready to convert. I think short-short-short homepages have great click thru, but I've seen in AB tests how easy it is to increasing the click thru rate of the homepage and end up with those people just falling out of the funnel one step later because they're not a good fit. Since ForceRank takes some work to setup your first question, I'd rather pre-qualify people then make them click through into a hard task just to understand what the product does. Make sense?


So that's the current state of the homepage (at least before we unveil our super awesome new integration). What do you think? I'd love to sit back and hear about the multitude of ways in which I screwed this up.

You can read the rest of this series in Building ForceRank a retrospective about the entire process. 

Try ForceRank Free


Topics: Tech, Product Design

Step-By-Step Prototype and Release

Posted by Jeff Dwyer

Jul 14, 2014 12:28:00 PM

This is part of our "Post-Natal" series on the development of ForceRank.it see Building ForceRank.it for the rest of the series.

So What Does Product Development Look Like?

I've talked a bit about how blown away I was by the speed of developing a new application in 2014, but what does that really mean? I thought the best way to show how it actually went down might be to just take a day-by-day look at what we accomplished. Enjoy!

Sept 6th Day 0

Login and a hello world. NBD, until you realize that out of the box you've got password reset emails, user creation, remember me etc, all running live on Heroku. 2014 is awesome.


Sept 7th Day 1

Installed Foundation by Zurb so out of the box have a nice nav, which is responsive and works on mobile.

Also static mockups of the voting screen. You can see the mock in Early Designs. The nice thing about getting this in HTML quickly was that I could start seeing what was going to happen on mobile, which was a concern because of the "drag left to right" design.




Sept 9th Day 3

Report page mockups finished. All of this is still static. Work is proceeding on the backend as well, but it was easiest to just plow ahead on the front and worry about hooking things together later.



Sept 18th Day 12

Work really only happening on weekends and still you can see that by day 12 we've got a functioning system. Real voting. Real rankings. I'd say that we'd spent about 30 hours so far.





And looking good on mobile. You can see in the third screenshot that I've cut out the comparer tool from mobile. This seemed like a fair tradeoff to me. Data-entry needs to work on mobile because you're going to receive an email asking you to vote. But data analysis can wait for the big screen.


So that's it! Two weeks from drawings to functional prototypes. Our next step was to stop coding, get out in the field and watch some people try it. 

You can read more about how they liked it and what we did next in The Building of ForceRank.

Try ForceRank Free  


Topics: Product Design

Post Natal Part 3: Technology Decisions: Why Rails is still great

Posted by Jeff Dwyer

Jul 14, 2014 12:28:00 PM

Happily, figuring out what tech we'd use was a very very small part of the ForceRank build out. We'd both used Rails in a previous life and our return to the fold was smooth sailing. Things have only improved since we left.


Here's our Gemfile. Pretty plain vanilla. But since breaking up with Rails seems to be the thing to do these days I thought it important to express just how fabulous our experience has been.

TurboLinks is fabulous. Not seeing the page flicker everytime you click a link just feels fantastic. I don't have numbers to prove that this has helped us, but every study ever done says that perceived website performance is the most important thing and I think this really helps us.


Hipster Coding

Well, we didn't actually go so old-school as Java, but with Rails being so passé, we felt like hipsters the whole time. Honestly though, for our use case "Post the form and redirect" felt like the newest hotness since AJAX (turbolinks is of course really important to make this feel good). Remeber the original DHH Rails video? "Look at all the things I'm NOT doing!" I felt like that the whole time. Look at me not compiling jade templates into javascript. Look at me not builing a parallel universe of Backbone models on the front end. Look at me getting totally sane error handling on forms out of the box by just using simple_form. Look at me not reading Ember documentation!!

Look at me not writing ANY authentication/user-management code because Devise just works.

Look at me styling a responsive site even though I am garbage at CSS because Foundation is fabulous.

Look at Stripe just being the most mind-blowingly developer friendly service you can use.

Look at better_errors just being embarassingly useful.

Look at letter_opener solving a problem I remember spending tons of time on in an earlier life.

Oh and Heroku. Yeah. So good.

As far as Heroku addons are concerned, HelpScout in particular seems to have fit the bill. Just seems to work. We tried Intercom and MixPanel, but you get into pricing tiers that are unaffordable very quickly.

Anyway have a peek a the Gemfile. Consider bucking the trend and not building an enormous single page app. If you're trying to solve a user's problem this basic Rails stack is the right answer for many many things.

Tame Your Trello Backlog


Topics: Tech

Ugly Mockups: How We Started

Posted by Jeff Dwyer

Jul 14, 2014 12:28:00 PM

This is part of our "Post-Natal" series on the development of ForceRank.it see Building ForceRank.it for the rest of the series.
Why Create ForceRank talked about the problem we were trying to solve with this product. So how did we think we'd actually do that? How do you turn an idea into a reality? Here were our big goals.


The site should be simple. Simple. Simple. One focus. No bells and whistles. We are big admirers of Doodle.com and we wanted it to feel just that easy. This lead to our second goal.

Get to Dog Food

Only build features that you must have in order to get as quickly as possible to the dogfooding stage. 

Mobile First

This is an interesting one, because honestly we get much less mobile usage than desktop and you could say that making everything work in mobile was a waste of time. But I would absolutely do this again. The fact is: if your design is simple enough to work well with one thumb your design is simple enough to work. Embrace the constraint.

No No's

Starting in our spare time we wanted to make sure that we didn't put anything in the way of forward progress. That's why we instituted our policy of "No No's", which means that the answer to "can I ..." is always yes. "Can I rip out the pricing page you did and totally redo it?" "Can I change the company logo?"  "Can I publish this blog post?" The answer is always yes.

Ship Early

Pretty much the current dogma, but it's dogma because it's right. Scratching one's own itch certainly helps in this regard because it means you can overlook lots of potholes as you try to solve your problem.

Charge Money

This is no doubt controvertial for some and we've already got great feedback from some people which basically amounts to "omg this is great! why are you hobbling yourself my charging money for this? this could be huge!!" But the fact is we aren't aiming for huge. We're aiming for really frigging useful. I don't want to solve anything remotely related to scale unless it's clear we've solved the fundamental problem first.

So how do you actually start? 

Well, you Sketch some things. And let these sketches be ample proof to all that you don't need a designer on day 1. Look at that horrid gradient! Look at those misaligned edges! No big deal. 


Mobile First: The trick with responsive design

You can see some horrible mobile-ish design in that first screenshot. It's horrible, because honestly I stopped using Sketch pretty early on. One thing I found was that responsive design was really much much harder in Sketch than just doing it live in HTML with Foundation. Responsive is just it's own thing. Maybe real designers have better tricks about how to think about the same design in 3 different widths at the same time, but it made my head hurt and doing static mockups in HTML and then dragging the window around to see how it responded felt so much easier. 

That said, Sketch was great about helping me understand how the voting and reports pages would work. 


The voting page

Pretty straight forward. A couple learnings here:

  • I really preferred a "drag from left to right" to a "re-order this list". It was more of a PITA, but if the list has any default order, everything is suspect of bias.
  • Ordering of choices was going to need to be randomized so we wouldn't insert the same bias for all respondants.
  • Left to right dragging was going to be hard on mobile. Honestly I wasn't sure what the solution would be it seemed like something we'd just have to try on the phone.
  • This design meant people wouldn't need to vote on all options. Was that ok?



The report page

This was probably the most important page to get right. If you ask three coworkers to vote on their priorities, you'd better deliver something useful. As you can read about in Why Build a Saas? I'd used color to help pull out the discrepancies between responses in my spreadheet. What wasn't clear to me, without mocking things up, was whether this was going to work at all for larger groups.

Should we show each choice in the order of the overall results, then what ranking each voter gave the choice?

I decided that was confusing, because there was no way to see the rankings of each individual. Instead I hit upon the solution you see above. Show each user's rankings in the order they ranked them. But use the color coding from the overall results.

I think this works pretty well. The "You" vote for "Level 0 - Level7" above clearly jumps out as being an outlier. Also the grey boxes work to show that Maureen didn't vote on everything.

Continue reading the rest of this "Post Natal" wrap-up here: Building ForceRank.it 

Try ForceRank Free


Topics: Tech, Product Design

Post Natal Part 1: Why Create a New Prioritization Tool SaaS?

Posted by Jeff Dwyer

Jul 14, 2014 12:28:00 PM

This is part of our "Post-Natal" series on the development of ForceRank.it see Building ForceRank.it for the rest of the series.

Why Did We Create This?

So one day I sat down and thought "you know what? I want to spend a lot of time trying to start a business that will most likely fail because #entrepreneurship". No wait, that's not what happened at all. Let's try again.

So one day I sat down and thought, "you know what? the world needs another small SaaS company!" No wait, it's not that either. Hmph.

So one day I sat down and thought, "Dammit we have like 10-15 different important projects and they're all good, but I can't tell how the rest of my team ranks them in importance and I think this lack of clarity on priorities is slowing us down because we're scattered." Ah that's it.

Coincidentally it occurred to me that this was not the first time I'd had this thought this. You might say "well, why don't you just ask your team?" and you'd have a strong point and of course I did, but I think there's something wishy washy that happens when we just talk about priorities. Have you had that happen? Here are my three experiences with prioritization.

Three Ways To Prioritize

The Cabal: You get lunch with your co-worker to chat big picture. You have a great big floating discussion about the market. Right about at the end of lunch you are both excited that the new analytics tool is really the most important thing and you decide that's #1 to increase your NPS score. As you walk back to the office, one of you says "of course I also think the new publishing tool and email notifications are going to be what drives growth".  And once again the priority list gets a bit hazy. Also the rest of the team may be on a totally different page.

The Stakeholders: You end up in a room with, "the stakeholders". Hopefull this is < 5 people, but we all know that sometimes this turns into 8 or 12. Oh and someone brings a talkative intern to watch. Four hours later everything gets tabled until you can all meet again in three weeks.

The Spreadsheet: The was one time when I'd felt a burning need to compare an endless number priorites with my Product Manager and I'd come up with a hacky spreadsheet that had really helped. It wasn't perfect solution. It was exceedingly finicky and a bunch of work, but it had produced some really interesting insights.

Basically what I did was list out all of the 40-odd possible projects that were floating around. Then I "forced" us to "rank" them. (You can see where I'm going here)  After that I did some spreadsheet math to calculate which ones were highest as well as the "relative overweighting" of each option. By highlighting the relative overweighting I was able to highlight the disagreements. It's not easy to read, but you can see in the image below that we had, astonisghingly the exact same rankings for #1, #4 and #6. Yet my #5 was her #42.  Sounds like that's an important disagreement to highlight to understand why something I thought was important she thought was next to useless.


Back to the problem at hand

Sadly this spreadsheet wasn't going to solve my problem. I really wanted to get the input of my product manager, my designer, the folks most in touch with user research and other engineers, and this spreadsheet was going to explode with more than two people.

But I loved what this spreadsheet did. It didn't just pick a winner, it showed me at a glance the differences and similarities between our thinking. I think we learned much more from the major disagreements than from the agreements.

  • When a PM sees that "advanced" feature highly ranked by an engineer, there's a good chance it's actually easier to implement than she expected.
  • When nobody agrees on the #1 priority but everybody agrees that the #3 priority is "Performance" you've got your answer as to what you should do next.
  • When the engineer sees that the project they've been noodling on in their spare time is #48 on their PM's list, it might mean that the company is pivoting away from that whole area.

Insights like these are what I wanted from my team and the intuition that we could build a simple tool to quickly help teams compare priorities is why we built ForceRank.

Now the trick is just building it...

Continue reading about how we actually built the tool here: Building ForceRank.it 

Try ForceRank Free



Topics: Product Design

Building ForceRank.it: A Product Management Post Mortem / Natal

Posted by Jeff Dwyer

Jul 14, 2014 12:27:00 PM


How We Birthed a Website

ForceRank is a prioritization and decision making tool for product managers. We've been live since January and have just tipped over into profitability. I'm using that to do a bit of a retrospective on the process so far. A guided tour of the genesis and early days of building ForceRank: The idea. The plan. The mis-steps. The horribly ugly mockups. The features we built and deleted before even launching :(

But first off let's clear up one thing. This is not a post-mortem, it's a post-natal! (It's weird that everyone declares their app "dead" before analyzing it right?) Things are improving every day and our new Trello integration is going to blow your socks off.

Outline of this Post Natal:

Building Products in 2014 

Overall I'm very happy with how the development process went. 2014 is indeed an amazing time to create products. Rails, Heroku & Zurb's Foundation are all so good it boggles the mind. Tracking our marketing efforts with HubSpot is light years ahead of anything else. To date we've spent ~140 hours of effort on building ForceRank, which includes blogging, marketing, product development, debugging, design. That's three and a half weeks of effort (spread out over 5 months) from zero to a product with paying customers. Amazing.

So what did we spend that time doing? Off the cuff I'd say that that broke down to:

  • 30% feature coding
  • 5% design
  • 20% styling
  • 20% blogging/marketing
  • 10% debugging
  • 10% scut work / annoying computer things
  • 5% user testing
In comparison when I started MyHippocampus in 2005 I think I spent:
  • 25% feature coding
  • 5% design
  • 10% styling
  • 0% blogging/marketing
  • 25% debugging (Fighting Hibernate took a year off my life)
  • 30% scut work (I can't tell you how much I fought with Tomcat)
  • 5% user testing

As you can imagine this has been far more pleasant and since I've actually had time to spend on getting the word out and polishing things this startup, with 140 hours is now substantially more successful than the startup I spent probably 3000 hours on in 2005. Yay Learning!

Tame Your Trello Backlog


Topics: Product Design

How would you decide what to do with $10,000?

Posted by Jeff Dwyer

May 10, 2014 11:36:00 AM


I've only just started All the Money in the World: What the Happiest People Know About Getting and Spending, but already it's terrific. I think far too much about money. I worry about the little purchases, alternately scrimping and binging on small things, all of which pale in comparison to those big/boring expenses which seem unavoidable. Sound familiar?

Well, I only finished Chapter One so far, so I don't have a solution for you yet, but I love the approach Laura Vanderkam is taking. Money is fungible, moreso than anything else. We have almost infinite options for what we can do with it, so, um, what should we do? Time for some decision making.

What would you do with $10,000?

Chapter one asks us what we'd do with $10,000. Well, actually she grants us $50,000 so that we can put $40,000 into our retirement funds/debts and feel like we're not being irresponsible when we consider what to do with the remaing ten.

So what should we do? Well, she has some fabulous examples which demonstrate just how much breadth is possible. Her "Commission a major choral work from an up and coming composer" example particularly stood out to me. Ten thousand dollars really is a lot, you can really change something. Or you can make one, small but meaningful tweak to every day of your life?


That would be quite a Happy Birthday Opus

Of course with great possibilities comes great decisions and that means prioritization. Hike through Mongolia? Endow a poetry award? Get a massage every week? What would you decide? And not incidentally, what would your partner choose?

Keepign quite about your dreams is no way to find happiness, sometimes you need to Rock the Boat. There's no better way to find out than to ask your partner, so I put together a sample ForceRank with the options listed in Chapter One. Click below to rank your choices and then you can share it with your partner to see what they would choose.

What would you do with $10,000?



Topics: Relationships

Committee Meetings Don't Need to Suck

Posted by Jeff Dwyer

Apr 12, 2014 12:42:00 PM


I'm sorry to say "suck". It's not a nice word and my mother raised me better than that, but the fact is it's true. Bad meetings can suck the life out of you.

In Meeting Zoology we looked at how personalities can turn a meeting into a mess. In An Evaluation Quickie we showed a really quick solution to improvement. But let's dive deep into what a bad meeting looks like. Here's a recipe I came up with for horrible meetings:

Horrible Meeting Pie (Serves 8-12)


  • 1 Executive who feels like they don't need to listen because they already know the answer
  • 1-2 Dominators who want what they want and don't care about the group
  • 2-3 Extroverts who actually like meeting politics and like to "play the game"
  • 2-3 Specialists who just need the group to approve their project so they can get back to work
  • 2-3 Quiet facilitator types who would like to achieve consensus



  • Do not send out an agenda.
  • Have the highest ranking individual arrive 20 minutes late
  • Repeat the first 20 minutes of discussion for them
  • Mix all personalities in a bowl until shaken
  • Let the dominators and executive argue back and forth for 30 minutes
  • With 10 minutes left let the exasperated specialists interrupt and demand that their project be accepted.
  • At 60 minutes, have half of the executives leave without deciding anything

I'm getting the willies just writing that. The good news is that IT DOESN'T NEED TO BE THAT BAD. Let's look at an alternative.

1) Collect Alternatives

First, we send out a collaborative document before the meeting to discuss priorities. That can look something like this:


The important thing is to let everyone speak their mind by adding what THEY think is most important.

2) Prioritize

Second, let everyone rank the choices in priority order (in a quiet room by themselves). Doing this forces everyone to make compromises, which creates empathy for the group. This can look like this:


3) Compare

Once everyone has voted, it's time to make a real agenda for the meeting. We can do this by comparing the results.


Ah, OK it looks like we don't even need to discuss the mission statement. And frankly in a 1 hour meeting we should probably make sure we stay on the "HR issue" and the search for the provost.

4) Outliers

But is that the entire story? Not exactly. When we compare the individual responses we can see that Stephen has a very different priority from the rest of the group. That doesn't mean we need to spend the entire meeting on it. But the meeting facilitator should make sure to take that up directly with Stephen.


Will using a tool like this solve every issue with your meeting? No, it surely won't. But by focusing the meeting on a single issue and having this data to understand the landscape of opinions you'll have an opportunity to use the precious face-to-face time to deal with the real issues.

Try ForceRank Free


Topics: meetings


What is ForceRank?

ForceRank is a prioritization tool for product managers. It helps people identify priorities, make tradeoffs, compare results and finalize a plan.

Try ForceRank

Follow Us