LeanWagon Gets Lean with PowerPoint

Greg Rublev, LeanWagon CEOGreg Rublev is an entrepreneur in the new lean startup mode. He didn't start out that way, but he learned from early failures and has quickly pivoted toward greater success. I talked to Greg to find out a bit about his startup, LeanWagon, and what he and his cofounders, Dean Hantzis and Dustin Haines, have learned in the process of developing and launching it. Hint: his favorite development tool is now PowerPoint.

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.

Superpowers for Product People

Agreeing on Priorities Is Hard

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!

Join Me at ProductCamp Boston - June 9, 2012

I'll be attending ProductCamp Boston on June 9th this year. It's my first time at an event like this - organized by and for the attendees - so I am hoping to learn a lot.

I find the egalitarian ethos of ProductCamp "unconferences" very appealing. (It's very user-driven.) We can learn as much (maybe more) from fellow product people as we can from consultants and experts. Who better to advise and teach than people who've been there?

ProductCamp Boston has set up a UserVoice forum to allow attendees to suggest and vote for sessions they'd like to have at the event. I proposed a session I call "How to prioritize requirements objectively and end roadmap arguments." Drop by the forum and vote for it (and/or whatever else you like).

See you there!

How to Conduct Customer Interviews

Giff Constable posted a very excellent summary of tips for what he calls customer development interviews. One of my favorites is number 5 on disarming "politeness" training.

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.

NetProspex Is Looking for a Great Product Manager

Product Manager is the best job in the world for those who are up to it. And a small, growing company trying to reinvent a tired old industry is the best place to do this job; you get to write science fiction and then guide the development team into making your vision real!

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.