ProductCamp Boston 2012 was really fantastic. The all-volunteer "unconference" format makes for some very real, gritty sessions by product people who are passionate about what they do. Not every session was as polished as it could have been, but one of the great things was that people in the "audience" jumped in with great insights. 

This year's event is May 4th at the Microsoft NERD campus in Cambridge. A lot of great sessions have been proposed this year, including mine on How to Build Roadmaps that Stick. (Please ignore the horrific typo in the title. UserVoice isn't configured to allow edits.)

In my session, I plan to build on last year's wildly successful session on prioritization. (Product people were actually out the door trying to find room to attend.) I talked about the objective scoring methodology I've worked out for prioritizing items for your roadmap. The slides are still available on SlideShare.

This year I will focus on how to translate your priorities into a transparent roadmap that will inspire your team to over-deliver and be compelling enough to keep the CEO off your back. I'll cover:

• Strategic goals 
• Objective prioritization
• Shuttle diplomacy 
• Transparent themes
• Punctuated equilibrium

I hope to see you there on May 4th, and if you have a moment, drop by the forum and vote for my session. That will help to ensure we get a large enough room this year!

There were 9 separate mobile devices or apps mentioned: everything from the Samsung Galaxy SIII, iPad and Nexus 4 to the Pebble ePaper Watch and Raspberry Pi micro computer. The only negatives in this category were for Apple (see below).

Entertainment services like Netflix, DirecTV, Comcast and Verizon FiOS all made the Shame list. This, I think, reflects our high-level of dissatisfaction with the entertainment distribution options available to us.

Of course, there were also nominations for business-oriented solutions like Join.Me, Nimble CRM, iBooks Author, Trello (in the positive) and Freemind and Ryma (in the negative). These generally received only one or two mentions each, though. Business is business, I guess.

Falls from Grace

The most interesting thing to me this year is how many former Fame winners were nominated for Shame this year. As a company, Apple won the Hall of Fame in 2007 with multiple nominations in many categories. This year, however, Aaron wrote:

"They've set my expectations so high over the years with wonderful and innovative products. But they've been mailing it in recently. iOS 6 and the latest round of products were.....boring. And in the case of Apple Maps, downright bad. I hope they turn it around and get back to showing me things that I never knew I needed."

And from Alexis, this:

"It doesn't seem like things can get any worse than a company CEO openly telling his evangelist consumer-base to use a competitor product until your own is fixed."

Apple wasn't the only one, though. Netflix won Fame in 2006 for their groundbreaking DVDs-by-mail service. They've clearly squandered that goodwill, though, by forcing customers to choose between DVDs and streaming and by making less and less content available via the latter.

Evernote hasn't appeared in this contest before but I was surprised to see this from Greg on the popular service (which I use daily):

"This used to be one of my favorite products, but they have clearly lost the way, although I still use it. Between removing the "new note" button, which is pretty much the only button people use all the time, and "upgrading" the app to be slow like outlook, it's gone way down hill."

Perhaps it is their former greatness that inspires people to speak up when things go wrong with their favorite products. Shame on Apple and these others for "losing the way."

Hall of Shame Winner

Apple wasn't the most frequent mention in the Shame category, however. Reading through the comments here, in a variety of LinkedIn groups I polled, and in direct communications with readers, the most shameful product of 2012 is clearly the new Windows 8 Metro interface.

"It's probably the worst user interface I've used. Extremely hard to find anything. Definitely seems like Microsoft is going backward."

"It is really bad and pretty much makes you start over using windows"

"Ugh! Is it metro or isn't it, can't it just decide?"

Hall of Fame Winner

2012 was clearly the year of Dropbox. It's been around for a while (and sharing files over networks has been around for even longer), but suddenly it seems like it's the app you can't do without.

"Now a paying user and even an evangelist, can't say enough good things about how easy and impressive this product/service super combo is."

"All my files in one place, accessible from anywhere. In particular I like it for a backup of files I develop or modify when traveling."

"It's great when I am in front of my daughter's computer and I need a file, and recently I've started sharing files with colleagues using it as well."

I listened to an interview with Drew Houston, one of the founders of Dropbox. He said that potential investors really didn't get their concept early on. People felt that online storage was just too boring, it seemed. The company launched anyway and, in Houston's words "Dropbox's simplicity has been a result of relentlessly sanding down the rough edges along the way."

This is the lesson for all of us in product development: taking something complicated (and maybe even boring) and making it great is a matter of getting lots and lots of little details right. And getting even a few of those key details wrong could make you the next Netflix.

It's that time of year and, though it's been 4 years since the last one, User>Driven is now accepting nominations for the 2012 Hall of Fame and Shame.

What is that, you ask? As before, the goal is to assemble the "top product triumphs and gaffes of the past year as nominated by you." So here's what to do:

Take 10 seconds right now and think of the one thing (product, service, website, software, gadget, whatever) that really works for you, that's so elegant in its design and operation it must be the result of a good feedback loop between the product designers and its intended market. Submit your first thought as a comment below.

And/or take 10 more seconds and think of the one thing that really irks you every time you have to use it because the product people clearly did not take the time to think about how it would really be used or try it out on a real-life person before getting it to market.

Even if your loved/loathed product or service isn't new this past year, if you discovered it in 2012, nominate it here.

As in past years, I'll be awarding something fun to the person(s) who first nominate the winning fame and shame products, based on votes (and my arbitrary opinion).

So what's it going to be? iPhone 5? Those great new pumps? Windows 8? Deadline for submission is January 15 so don't delay!

Without further ado, here are my observations of what it's like to be a product manager during the holidays: 

1. Your wish list is prioritized, categorized and cross-referenced by application. My inner ski bum would totally use these technical gloves!
2. You've provided use cases for the exercise equipment you'd like your spouse to research for you. As a full-time professional, I want an efficient way to fit exercise into my existing schedule so that I can avoid premature decrepitude.
3. You suggest a daily stand-up meeting to check in with your spouse about preparations for the big holiday shin-dig you host every year. S/he is not amused.
4. You ask your kids what problem they are trying to solve when they ask for a toy. (Shout out to Paul Young!)
5. You've created a house-cleaning roadmap months in advance. We shouldn't vacuum until the 24th but can we bake extra pies at Thanksgiving and freeze them?
6. You asked your spouse to produce a mockup of the planned table arrangements. We can have the kids do some user testing to determine if there is enough room for all the side dishes!
7. Family and friends ask your advice on what gadgets to buy for their spouses, how to speed up their computer or if they should buy Google stock because you "work in computers."
8. You use evite to plan a holiday party and set up a UserVoice forum to collect ideas for the theme. What do you think it means that we got 8 votes for "just Christmas already?"
9. You work to ensure there is at least one gift for your significant other in each application area, including clothing, electronic entertainment, non-electronic entertainment (books), romantic, pampering (if female) or sports/cars (if male) and food. How else would you do it? 
10. You can't resist making a list of things product managers do at Christmas while everyone else is drinking eggnog. All the other product people need something to read over the holidays, right?

Hope you found this amusing. What are your thoughts on the holidays as a product manager?

Ken Norton has provided a terrific set of guidelines and (usefully open-ended) sample questions to elicit the right kind of interview discussion for product manager positions. If you're hiring (or looking for a job) in this space, check it out.

The one place my experience disagrees with his is that I prefer to hire people who were not engineers in prior roles. It's not a rule with me, but it is a preference. I find that if someone has a logical mind they can learn the technical bits but that being a good PM starts with the innate product instincts and leadership ability Ken describes plus good communications ability. Those things are much harder to teach.

Do you need a complex, custom-implemented enterprise tool or something simpler?What can we learn from continued consolidation in the requirements management software space? The 1st of my lessons about the fall of Ryma seems to apply here. In that article, I argued that the market for enterprise product tools was limited to very large companies. Accept's position as the solution for "the toughest planning challenges," helping companies "stay in sync across all divisions," fits that model. It also fits with Artemis' focus on enormous projects like "the new Terminal at Heathrow as well as large nuclear submarines." (Don't believe Artemis is only for large projects? Check their website's "Industries" menu; they list only "Nuclear" and "Defense.")

Ryma was hit hard in the great recession and they found that the companies that stuck with them through severe cost cutting were those that had a large portfolio of projects all around the world. Execs found it useful to have a top-down view of their entire portfolio with a consistent way of quantifying ROI. The trouble was, Ryma did not provide value to the product people themselves, the users. It didn't help them do their jobs better or more efficiently. In fact, its complexity created extra work for them.

This means these kind of heavyweight enterprise tools are never going to be of use to the large majority of people with roadmap responsibility who work in smaller organizations, where time to market is more important than portfolio management. The tool that can handle all of the dependencies, approvals, regulatory requirements, custom rules and nested hierarchies of DOD projects is just not the simple, elegant solution that will help most of us cut through complexity and make decisions efficiently.

Tell me, what kind of tool do you need to do your job?

1. There is little enterprise market for product management software

"PMs have no budgets," a former Ryma executive told me. People at Ryma believed that product management is one of the major keys to success for companies, but "as soon as budgets get cut, you're the first one out."

Ryma started back in 2001 to provide a simple tool for product managers. Former execs explained that they "just wanted to improve the lives of PMs." The tool expanded and became more complex over time, though, and many PMs found it was more work than it was worth to use. Ironically, the complexity was the direct result of feature requests from product managers. Ryma made an ongoing practice of interviewing its customers and incorporating their feedback. That's good practice, right? This can serve as a caution to us all. It's the classic conundrum of trying to please everyone leading to not pleasing anyone.

After the recession led to the loss of half of their customers, the company discovered a surprising phenomenon. Use of FeaturePlan at many companies who had stayed with them was not being driven by product people but by upper management. In fact, PMs often resisted using the tool but executives insisted because it gave them visibility into their whole product portfolio and, among other benefits, helped eliminate duplicate efforts.

2. A product needs to provide value to its buyers

So it turned out Ryma's customer wasn't the product manager at all, but the executive team. That's who was getting value from the tool, so that's who was willing to stand up and say it had to be part of the budget even when costs were being slashed.

The Ryma team ran with what they'd learned and built an in-house consulting practice to help executive teams establish consistent processes and get the most out of their product development efforts. Increasingly, according to people I spoke to, the sales mix changed to larger, more services-centric deals and FeaturePlan accounted for only about half of the revenue mix. The company was constrained by the thinner margins of a service business and by their ability to hire and train consultants, but they were growing once again.

3. VCs will happily fly you into a mountain

The success of Salesforce.com has spawned a lot of venture-backed imitators, and many investors have looked at their growth and valuation with envy. "Investors wanted an exit, not dividends," confided one insider. So despite positive changes, it seems Ryma's long-time investors hired a new CEO with the mission to make Ryma into that kind of SaaS company, changing the focus to large numbers of seats and a very lean organization without a lot of in-house consulting staff.

Ryma's dreadnought-class product, long sales cycle and existing pipeline of consulting work, however, didn't fit that model at all. And Michel Besner (the new CEO) seems to have remembered too late Guy Kawasaki's advice about cash being "what keeps the doors open." I heard from more than one source that the new management simply "spent all the money."

4. Bonus lesson: know what you're buying

A number of people have said that OneDesk got a great bargain buying Ryma at a fire sale. I am not so sure. Another interpretation of events is that the product they bought had become so complex that it simply does not provide sufficient value on its own. It requires a large investment in consulting services to make it usable, and OneDesk is not as well equipped to provide those services. Spokespersons for OneDesk indicate that they have retained contracting relationships with 3rd party consultancies and with a small number of former Ryma employees, but this seems very much like the model that didn't work under the previous leadership.

Initially, OneDesk's acquisition made no sense to me. OneDesk offers an inexpensive cross-departmental suite for small companies while Ryma had built a high-end point tool for enterprises. I think I get it now, though. The thing they share is a central (though not exclusive in the case of OneDesk) focus on the product manager. Brendan Walsh, former Marketing Manager for OneDesk, said their goal is to be "the Salesforce of product." That's ambitious. If you look at Ryma's failure in building enterprise value from the PM out, though, it may be unrealistic to build a large enterprise business around the PM.

So what does all this mean for Reqqs, my attempt to provide value to product people? Not much, I think. I've never been interested in building an enterprise tool or a cross-departmental suite. Reqqs is meant to focus on the needs -- and modest budgets -- of the majority of product people (most of whom work in smaller teams) by providing a simple, affordable roadmapping tool.

A former Ryma exec said, "Somebody will come one day with a tool that is so simple and flexible but will actually truly help the PM." That is what I am aiming for with Reqqs. If you'd like to be in the loop on development efforts, stop over to reqqs.com and weigh in.

Let me ask for your help, up front, though, in keeping it simple so it stays accessible and useful for everyone, even if it doesn't do everything everybody might want.

This news and rumors of layoffs at other long-established vendors confirmed for me, though, real changes that are at work in the software industry -- changes that, ironically, many product management tools have failed to respond to. Product people want lean and simple tools that do one thing well and are focused on making people productive right away with an intuitive and configurable UI.

As readers of User>Driven know, I am at work on a tool like this called Reqqs. This is not just my self-serving interpretation of events, though. Here is a sampling of quotes from here, here and here on Ryma's passing.

Its biggest problem (my opinion) was that it missed the SaaS and Web 2.0 wave by about 3-5 years

I think they could have succeeded if they had put more emphasis on usability and less on complexity. Sometimes simpler is better. 

FeaturePlan was slow, and cumbersome to enter and find things. People got lazy and started building a backlog on their own PCs.

Personally, I want to be in the business of managing products, not managing a product for managing products.

I used MS Excel posted on a collaboration site and was very much more effective in managing features. 

My colleagues were worried that this tool needs custom integration that might be too expensive. At the same time, their demo was focused on features that did not matter to us.

Their sales team was more worried about selling expensive consulting services to "customize" (i.e. make somewhat useable) the product.

For a company supposedly knowledgeable about Pragmatic- they did not follow the Voice of the Customer methodology. Their product concept was decent - but the execution was not. 

At the same time and despite these sentiments, many loyal customers and partners are sorry to see Ryma go:

I have had the privilege of getting to know several of the members of the RYMA team and I want to wish them the best as they move to the next phase of their careers.

I'm sorry to see them go. We've been using FeaturePlan for about 7 years. There are lots of products that are good at requirements tracking and management. Very few that are a tool for the front-end of Product Management: synthesizing customer problems into features and requirements.

Could Ryma have pivoted and continued meeting the changing needs of product managers? Given time enough and an openness to customer feedback, maybe so. Ryma's CEO (new this year), Michel Besner, had a pithy response to that question.

I guess 6 months was not enough to turn the company around ...

This does not have to be the end of something, though. Perhaps -- in the spirit of Joseph Schumpeter's creative destruction -- it can be a new beginning for the industry, for the employees of Ryma and for the product community.

What do you think? Post your thoughts in the comments below.

Greg Rublev, LeanWagon CEO

Launch Early?

The usual startup advice is to launch early and start getting feedback so you can improve and expand on your original idea based on what you learn. How do you do that, though, when your first effort really doesn't work as a business?

Greg and his partners did all the right things. They kept expenses low, working out of space borrowed from a friend, 2 of them keeping their day jobs at least part time, and paying employees with equity rather than cash. They quickly launched a simple site that focused on one thing: the idea that people will lose weight more consistently with social support. And they got a lot of sign-ups quickly. They were on to something, clearly.

But they soon found that users' initial enthusiasm waned and engagement began to drop off. Soon after signing up, people were just not coming back.

Learn Fast

Greg did a very smart thing then. He picked up the phone and started calling users to ask them why. He quickly learned that they did like his concept. They signed up and wanted to participate but they just weren't sure how. The site, it turns out, wasn't doing a good enough job of letting people know what they could and should do there to make it work for them.

It just so happens that right about then, Greg was reading The Lean Startup, Eric Ries' book on how to continuously innovate toward success. In that book, Ries argues that to build a business you shouldn't start with a product. Rather, you should start with questions.

Greg had a hypothesis that people would benefit from social support when trying to eat healthy and lose weight. And he quickly learned that people found this idea appealing, but did he have to build and a launch a website to validate this hypothesis? And was the website he built - its features, branding, user experience and business model - the best way to address this need in the market?

The Lean Startup philosophy says you should validate (or invalidate) your hypotheses as quickly and cheaply as possible so that when you are wrong you still have the time and resources to refocus and try again. This gave Greg a framework he's now following to "pivot" (the officially sanctioned term) and test his way to success.

Test and Learn, Iterate then Test Again

Greg began experimenting with new features and new variations on LeanWagon - but all in PowerPoint. He didn't want to spend all the effort to develop and ship a new version of LeanWagon without first testing his hypotheses about how it could be improved first. So he took screen shots from the site, placed them on slides, tweaked them this way and that, and created mockup flows through a hypothetical version of the site. He then put these mockups in front of users who had signed up but stopped coming back.

The feedback was incredibly valuable. Every session he did brought fresh insights about what confused users and what interested them, which options they would choose and which they would ignore.

A simple thing they learned early on was that no one - not a single test subject - would use the Facebook sign-up feature they had spent a lot of time on developing. So, even though people on the team had felt very passionate about including it, they went with what they had learned and dropped the feature. Why clutter up the interface and increase their code maintenance and testing burden for something no one wanted?

Another interesting insight was that nearly all users chose a specific one of the three diet plans they offered. Unfortunately, it was the one that they knew was hardest to stick to and that had the worst rate of drop off in engagement. So they made the decision to skip the plan selection screen all together and put everyone in what their nutrition advisor had told them was the most sensible and sustainable plan. Here was an example of listening closely to your users - but choosing not to follow their desires.

From Drawing Board to Real World

Today, Greg and his team are back in development mode, coding a new version of LeanWagon that they feel much more confident about. The new flows, options and features are based on the testing they did in PowerPoint with real users. Each change is the result of a successfully tested hypothesis about what will work for users and drive more engagement.

What happens next? Greg says they will continue this model of testing their way to success indefinitely. Tools like Google Analytics will help them track engagement with the site and Google Optimizer will help them A/B test variations in production and see what works best.

PowerPoint remains his tool of choice for significant changes, though. You can't beat it for a quick way to test ideas without code.

I've been talking to product managers, project managers, business analysts, development managers and other product people about the challenges they face in their jobs. What I hear most is that the number-one issue is how difficult it is to set priorities for their engineering teams on what to build first. This is no surprise to me as a long-time product manager. Roadmapping is the skill I've spent the most effort honing over time.

Talking to these folks, I've also learned that the number-one problem with this number-one issue is not making a reasonable decision to start with, but making it stick. The hard part, it turns out, is getting buy-in on those priorities from all of the stakeholders around the company and among key customers and partners.

Spreadsheet Models Can Be Some Help

Through nearly 20 years of experience in developing products, I've devised a methodology that allows a product person to socialize a set of priorities, get buy-in on them and publish a roadmap that sticks. It derives clear and objective criteria from company and project goals. The approach results in a lot less arguing and a lot more building of results-driving products. 

I've used spreadsheets for this, as many experienced product people have, continuously evolving my template to take into account multiple business benefits and calculating an ROI score based on level of effort. But the spreadsheet itself is a separate document from requirements or stories or roadmaps, and it quickly gets out of date or becomes a paperwork burden.

It can also be hard to share and even harder to consume. A detailed spreadsheet is good for developing a roadmap but it's not good for communicating one. I've written before that what I think is really needed is a new product -- a simple, inexpensive roadmap tool. I'm now starting to build such a tool. I call it Reqqs.

What If You Could Wear Superman's Cape?

The typical product manager, program manager, tech lead or business analyst is a really extraordinary person, a kind of tech superhero. They keep a million balls in the air at the same time, get input from virtually everyone, speak fluent CFOish, Enginese, Supportic and Salesish, and generally do an amazing job of giving thoughtful direction to their development teams. I haven't met a single one, though, that didn't say they couldn't use some help with all of that.

So Reqqs is focused on unlocking the key superpower within product people -- namely, prioritizing and getting buy-in on product development roadmaps. It's designed to do that by providing a transparent and objective scorecard that's tied to your goals and that's dead-easy to use and to socialize.

Reqqs is a webapp that makes the process of getting to consensus on priorities easier than it's ever been. Way easier than Excel, or Sharepoint, or Google docs, or any of the heavyweight enterprise requirements management tools. And way easier than JIRA or any of the other engineering workflow tools as well.

A Tool By and For Product People

Product people are a unique breed that lives between the development team and the rest of the world. We're not really developers, not really marketers, not really salespeople, not really in finance. Or maybe we're on all of those teams, but they all have their own tools and none of them are really built for us. 

Reqqs is conceived and designed by product people for product people, designed to help us communicate better with all of those departments, with executives in general, with partners and customers -- with all of our stakeholders.

Up and Up

To bring Reqqs to market, I've founded a company focused on unlocking the hidden superpowers in all product people. It's called UpUp Labs after a certain superhero's well-known catchphrase. We're a small team, and we intend to stay that way -- but we have decades of product development experience to help guide the design, development, marketing and support of Reqqs.

We're at work building and refining Reqqs now. If there is one thing we've learned over time, though, it's that we can't do this alone. What we most need is your help to make sure it meets your needs as a product person.

You Can Be Part of This

I expect Reqqs to make money. But to be honest, what I most want is for product people all over the world to get a boost from it, for it to help them be more effective at this challenging job. Let's do this together. Help me make Reqqs into the tool we've all wished for but could never find.

Drop by www.reqqs.com, check out the proposed features and mockups for release 1, sign up to be notified when Reqqs is available if you like, and leave your comments, thoughts and ideas on what you need Reqqs to do for you. In return, I promise to listen.

In the meantime, use your superpowers for good!