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!

People are trained not to call your baby ugly. You need to make them feel safe to do this. My approach was to explain that the worst thing that could happen to me was building something people didn’t care about, so the best way they could help me was absolute, brutal honesty.

My other favorite is what he says to do after the interview: Look for patterns and apply judgment.

Customer development interviews will not give you statistically significant data, but they will give you insights based on patterns. They can be very tricky to interpret, because what people say is not always what they do.

You need to use your judgement to read between the lines, to read body language, to try to understand context and agendas, and to filter out biases based on the types of people in your pool of interviewees. But it is exactly the ability to use human judgement based on human connections that make interviews so much more useful than surveys.

The way I do this in my own work is to collect my notes on a series of interviews and then review them one at a time, recording the incidence of certain problems, requests, needs, characteristics and other concepts. Extracting structured information from unstructured notes, though (as Giff says) not statistically valid, does help to bring out patterns. See my entry on qualitative vs. quantitive research methods for more on this and what to do next.

As a key member of our talented product group, you will lead a development team charged with developing, launching and managing products for NetProspex. This extends from increasing the growth and profitability of existing products to developing and launching new products for the company. You will build products from existing ideas, and help to develop new ideas based on your industry experience and insights gleaned from customers and prospects. You must possess a unique blend of business and technical savvy, of quantitative analysis skills and creativity; a big-picture vision; and the drive to make that vision a reality. You must enjoy spending time in the market to understand their problems, and find innovative solutions for the broader market.

You must be able to communicate with all areas of the company. You will be hands on with engineering to define product release requirements. You will collaborate with marketing to define the go-to-market strategy, helping them understand the product positioning, key benefits, and target customer. You will also serve as the internal and external evangelist for your product offering, working with sales and key customers.

A product manager's key role is strategic, not tactical. The other areas of the business will support your strategic efforts, though you will sometimes also be asked to help support their work as well. This position reports to the VP of Product (that would be me).

KEY RESPONSIBILITIES

• Manage the entire product life cycle from strategic planning to tactical activities
• Determine market potential, trends, and opportunities
• Specify market requirements and manage backlogs for current and future products by conducting market research supported by on-going interaction with customers and non-customers
• Drive the success of your product across teams (primarily engineering and marketing) through market requirements, positioning and messaging
• Lead development of a company-wide go-to-market plan, and collaborate with all departments to execute
• Analyze potential partner relationships for the product and collaborate with business development to execute

REQUIREMENTS

• 5-10 years of software/internet product management experience
• Knowledgeable in technology, passionate about its possibilities
• Excellent creative instincts, a deep understanding of technology and strong project management and analytical skills.
• Entrepreneurial experience and success creating great products is highly valued
• Computer Science or Engineering degree or work experience a strong plus
• Significant people and organizational management skills, a natural leader and consensus-builder
• Roll up the sleeves attitude, proven ability to execute
• Strong communication skills with the ability to evangelize the merits of NetProspex products internally and externally
• Position requires occasional travel to customer and non-customer sites and industry events in North America

The position is posted formally on our jobs page. In the meantime, if you're interested and you think you qualify, email me with resume and cover letter at jobs@netprospex.com. I look forward to speaking with you.

Incidentally, this job description was adapted from the excellent sample description developed by Steve Johnson at Pragmatic Marketing. Thanks, Steve.

Young Jedi product manager

Surveys from Pragmatic Marketing, Jama and Quantum Whisper paint a pretty detailed picture of a product manager and his or her job. I've assembled this composite persona from that information, my own experience, and many discussions with other PMs over coffee or beers.

I've recorded it here to get your input and feedback. Is this you? Is it like other PMs you know? With your help, this will form the core user and buyer persona for a simple, affordable requirements and roadmap tool. Let me know what you think in the comments below.

Luke the Product Manager

Luke is a product manager in the software industry. He’s 39 years old and has a college degree. He wonders if he should go back to get his MBA because many of his colleagues have one but he doesn't have the time because he is already working 50-60 hours a week. He makes $117k per year in total comp, including a bonus he gets most of, most of the time.

Luke's Team

Luke is one of a group of 6 product managers at his company, reporting to the VP of Product Management who reports to the CEO of his company. Luke is responsible for 3 products and $23 million in annual revenue.

He works as part of a small development team of 18 people. The team is spread out over multiple locations and time zones, so Skype and Microsoft SharePoint are every day tools for him. Recently, however, he’s also been looking at Google docs for sharing.

Luke's Job

He’s good at his job but puts in long hours, including frequent evening and weekend work, and never feels as though he’s really caught up. He wants to spend more time talking with customers, doing win/loss analysis and thinking strategically about the future of his market and where his product should go. Instead, he spends many hours composing, organizing, prioritizing and communicating requirements to engineering and to the many other constituencies around the company that need to know about them.

As part of his job, Luke must gather information about market requirements and communicate information about these requirements and the status of development efforts to meet them to a variety of stakeholders, including people in marketing, sales, sales engineering, customer support, finance, development, architect, C-level management, partner, customer and prospect roles.

He’s getting more attention from the C-level execs at his company, which is gratifying and he assumes will be good for his career, but it is also creating more work in preparing materials suitable for that audience.

Luke is managing his first nominally Agile project, learning as he goes. The team is not following a pure Agile process, however, preferring to retain some of their established methods, habits and tools.

Luke's Process and Tools

Luke is a gadget hound, carrying iPhone and iPad wherever he goes. He meticulously records interview notes with customers in Evernote and captures feature requests in Excel. He dashes off UI mockups in Balsamiq.

Luke writes requirements in Word as a single Product Requirements Document, uses Excel to prioritize those requirements, and uses PowerPoint to communicate the committed roadmap.  Luke’s PRDs and Prioritized Feature Lists contain a lot of information and a large number of features to manage. He usually has to make multiple versions of each type of document as projects evolve, and it is a challenge to keep them all up to date and in sync. 

Luke enters features into JIRA one at a time once they’ve been agreed to. In that process, he modifies and makes the requirements more detailed, obsoleting those parts of the PRD and leaving unimplemented features orphaned in a doc no one will look at again.

Luke wishes he had a tool for managing requirements that was easier to use because it would save him a lot of time and effort in maintaining and publishing his many disparate documents.

Luke's Work Style

Luke is fairly technical, thanks to his background in engineering and as a sales engineer. He is also an excellent communicator, which makes him good at bridging the gap between business problems and what Engineering needs to know to solve them.

He is a good listener, very easy to approach and talk to. He likes learning about people's jobs, their challenges and goals. Luke asks good questions. He is also very analytical and does a good job synthesizing all he learns into a coherent plan. His most difficult challenge is prioritizing the myriad requests and ideas he gets for features, bug fixes and other work in a way that serves the strategic needs of the company, keeps customers and other stakeholders happy, and can be explained clearly and defended using objective criteria.

Does this sound like you? Post your thoughts in the comments.

Duh.

Accompa's own website says:

"Studies by organizations such as Forrester Research show that there is a high incidence of "shelfware" among companies which purchased requirements management software. The primary reason for this problem? Their users found the software too hard to learn and use."

And yet Accompa's tool still looks like a challenge to get started with to me (and it's a minimum of $200/mo).

So what's a product manager to do? Gather requirements, of course! I'd like to get your input on what a simple, inexpensive roadmapping tool would need to do. For clarity, I define roadmapping as requirements gathering, prioritization and communication.

If you'd like to weigh in in what such a tool would need to do for you in your job, enter your ideas here (or vote for ideas already there). You can see what others are voting for and I will publish the overall results in a few weeks.

Social Industries - New Tech But Not Old

It's no surprise that tech companies are among the most connected through the new social media. But I thought it was interesting that the auto industry is at the very bottom, including dealers, repair shops and parts stores (all in the bottom 10).

Social Jobs - Finance But Not The Board

I found it surprising that Finance folks (plus M&A, less surprising) were ranked number 2 in connectivity, after recruiters. Having absorbed that, though, I thought it was fascinating that Board members were at the very bottom. Isn't that where Finance folks go when they retire? maybe it's just a generational thing.

Social Companies - Tech Plus Newspapers

Again tech companies dominate the top 10 most-connected companies, but interestingly, the New York Times trumps them all and grabs the number one spot. Could it be David Pogue and Walt Mossberg all by themselves?

Check out the report on NetProspex.com. It's a free download and it's fun to check out your own industry, job and region.