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!

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. 

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?

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.

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

KISS

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 

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 

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:

• Why Create ForceRank?
• Early Design Goals
• Technology Decisions
• Early Days
• Homepage Iterations
• Features that didn't make it
• Samples
• Marketing
• Next Steps: Product Manager Focus & Trello Integration

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

• 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!

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!