Better Product Managers, and Product Management

Archive for the ‘Best practices’ Category

Customer Development Interviews How-to: Finding People

“OK,” you say, “I’m convinced – I need to talk with potential customers to make sure my startup/product/service idea has potential.  But how do I find those people?”

Finding People

AdWords / Facebook Ads / Tweets.

Summarize your idea, invest some money in getting it in front of people who have expressed intent by searching for that term, clicking your ad, clicking a link.  (Read the original SEM on $5/day post for details.)

I haven’t used Twitter for this much yet, but my theory is that it may be a more effective way of reaching people (I am much more likely to click on links that appear in my hashtag saved searches than I am to click on an AdWords or Facebook ad.)

Twitter Search.

Look for people who have already discussed a similar product, problem, or solution and address a tweet directly to them:

@username Would love yr feedback on [product/problem/solution] – shd only take 2mins [URL] thanks!

Some people will ignore this, but many more will feel a bit flattered that they’re being asked.  Use this judiciously – more than one or two of these tweets per day and you’ll look like a spammer.

Google Alerts.

Set up Google Alerts for your product/problem/solution (you should have done this already anyways) – and when it finds relevant blog posts or comments, email those people and ask for their feedback:

I read your [post/comment] about [product/problem/solution].  I’m currently trying to validate a related idea and I think your opinion would be very valuable to me – could you take 2 minutes and check out [URL]?  Thank you – I’d be happy to return the favor any time.

Ask for introductions.

People are generally happy to make introductions for you, provided you do 3 things:

  • Provide the exact text that they can copy and paste into a tweet or email (They’re doing you a favor! Make it as easy as possible for them.)
  • Tell them exactly how you are going to communicate with their contacts (They’re risking a bit of social capital for you – if you are a jerk to their contacts, that will reflect badly on them.  Be very clear that you won’t spam or annoy people.)
  • Tell them your goals (What do you think you’ll get/learn if they make this intro for you? People want to know that they’re contributing to a bigger picture!)

Email Request Template

I have a quick favor to ask.

I’ve got a product idea that I’m trying to validate with [type of customer]. My goal is for them to visit my splash page at [URL] and indicate their interest (or lack thereof).  I will only contact them if they explicitly give me permission to do so.

Could you send this message along to people you know who fit this target?  (Feel free to change it a bit if you like):

[Message - be sure to include the goal, the URL, and your contact information]

Twitter Request Template

I have a quick favor to ask.

I’ve got a product idea that I’m trying to validate with [type of customer]. My goal is for them to visit my splash page at [URL] and indicate their interest (or lack thereof).  I will only contact them if they explicitly give me permission to do so.

Since you have a number of followers who are the type of customer I’m trying to reach, could you tweet this for me? (Feel free to change a bit if you like):

[Message - include the URL, the topic, and keep it under 115 chars so it can be easily retweeted]

Asking for the Interview

You may be wondering, “so what is this URL I’m sending people to?  Can’t I just have people email me?”

You have three main goals with your splash page:

  1. Communicate your idea in 10 seconds or less (seriously, that’s about how much time you have to grab someone’s attention)
  2. Offer something interesting to the people who visit
  3. Get contact information so you can ask for the interview

    #1 is up to you (there’s a whole other blog post I could write about that…).

    #2… when I say “offer something”, people generally think that means a tangible incentive.  You can, but you probably don’t need to – people like being asked for their expert opinion, they like the feeling that they’re contributing to something, and they like being part of a select group who gets a sneak preview at something.

    You can cover #2 and #3 with a well-written survey template.  You can see the one we’ve used for the Survey.io beta, or here’s a partial screenshot:

    FYI – I’ve used surveys with these 2 questions for multiple products, and so far, overall less than 20% of ALL respondents to this survey leave these blank – the vast majority choose at least one way in which they’d like to give feedback, AND give an email address.

    Coming next week:  I’ve got email addresses – now what?

    Why “Innovation Teams” Fail (and how to prevent it)

    It’s OK to say you belong or reside within and have an innovation team within a corporate/business environment. Innovation is not a dirty word. - Carl Knibbs, Cup of Innovation, Anyone?

    I agree!  I’ve seen two reasons why “innovation teams” are poorly regarded within larger organizations.  Actually, they apply to pretty much any type of “special task force/skunkworks” team:

    1. Lack of internal credibility, i.e. the “what the heck does the INNOVATION team do? Yeah, I’d like to be an innovator instead of having real work to do” reaction
    2. Silo syndrome, i.e. “the rest of us don’t need to be creative, we have an innovation team to handle that.”

    (more…)

    Front-Load the Pain

    This is a story about a bug that I still think about.

    It could have been avoided if I’d been able to successfully convince us that we should sacrifice a little bit of backwards-compatibility.  It would’ve meant customer complaints. Some customers would have delayed their upgrades; some may have even threatened to not renew their contracts (although the chance of them carrying out that threat was incredibly slim.)  In other words, it’s a decision that would’ve caused a lot of up-front pain.

    Here’s the story, in short:

    Product redesign.  Fundamental change to product functionality and positioning (and one that had been well-researched, thoroughly user-tested, and really well-received.)  Just one problem: we’d made the promise that the layout of the UI would be backwards-compatible (as a white-labeled software package, we were styled to match the branding and templates of the ‘parent’ website).  “You won’t have to change your templates or stylesheets or the order of the modules on your dashboard,” we’d said.

    But it just wasn’t possible.  When you add information, you just can’t fit within the exact same dimensions.  After a lot of reworking, we had a lot of workarounds:  Customers could use flexible-width instead of fixed-width.  They could shift from a double-column to a single-column layout.  They could keep the double-column layout but make one column slightly wider than the other.

    I was mortified, frankly.  It was a problem I should’ve caught earlier, and now that we were rapidly approaching release dates, I had no solution. I made the only recommendation I could.

    “They’ll have to make a change,”  I said, “but we can help them make it as painless as possible.  We can do the stylesheet revision work for them to make it as close as possible.  Their end users may not even notice.”

    I was overruled.  We’d told them backwards-compatible UI layout, that’s what we’ll give them.  Figure out a hack to make it work.  Postpone the pain.

    And here’s the consequences:

    So we hacked a solution for the first customer.  Reduced font-sizes, sliced off a few pixels of whitespace here and there.  It worked – kind of.   But hacks aren’t good at solving for edge cases.  So the bugs started rolling in – in certain circumstances, the layout would break again.  And we’d fix that issue, but then the next customer would find a different way of breaking the layout.

    I can’t count the number of hours devoted to variations on this one bug.  Customer service had to deal with it, design, professional services, engineering, QA – every fix touched multiple departments, and never fully resolved the issue.

    For all I know, the same bug is still being hacked on, 3+ years later.

    It would’ve been painful to tell customers that we had to go back on our promise and break backwards-compatibility.   But that single decision probably cost tens of thousands of dollars in productivity loss.  Hours and hours in opportunity costs.  And the customer goodwill we’d hoped to preserve was at least somewhat eroded by the fact that we kept breaking their layout, anyways.

    Pain fades with time. (Anyone who has lived through a website redesign knows this: you’ve seen a ton of vitriolic customer feedback, followed by little to no actual effect on traffic, followed by people forgetting that it was ever any other way.)  But trying to avoid pain at all costs takes constant, ongoing effort.