Better Product Managers, and Product Management

“That’s the way it’s supposed to work.”

If you feel the need to say this, then you have screwed up.

Maybe your copy was confusing. Then you say, “Actually, I don’t think our app explains it very well – this is how we had envisioned it working: [describe] – does that make sense to you?”

Maybe you were forced to add security features that were un-user-friendly. Then you say, “The reason it works that way is [explanation]; I know it isn’t an optimal user experience but here’s the benefit: [describe]

Maybe you were just wrong about what an intuitive user workflow would be. Then you say, “I agree, it is confusing.  Can you walk me through how you use it, so that I can better understand how we might make it better?”

When you start feeling defensive, it’s usually for a reason – you know something isn’t really quite right.  Use that feeling to learn something useful.

…It’s better than being a time waster.

I’m going to pull a number completely out of you-know-where and estimate that a full 20% of time in software companies is wasted on completing tasks to avoid the appearance of flakiness.

Product managers are pretty guilty of this, but they’re by no means the only offenders (and when product managers do this, it’s often because of a corporate culture that encourages it, such as bonuses being dependent on the % of your features that are completed and released.)

Here’s what happens:

• a need is identified – a new feature, a bug report, an inefficiency
• requirements are written and agreed upon
• work begins

– but then something happens.

Maybe further customer interviews reveal that the new feature isn’t really that valuable after all.  Maybe watching your usage metrics shows that the bug – as much as it may irk you – is not affecting your customers’ use of the product.  Maybe that improved database query really isn’t needed at current usage levels.

Whatever the reason, the conclusion should be clear: we should stop working on this.

But we don’t.

“We should just finish it – It’s bad for engineers’ morale to have a half-finished feature sitting around.”  No — it’s worse for morale to have a fully-finished feature released but still just sitting around (and probably cluttering up the UI and generating more customer support costs.)

“We may as well do it now even though we don’t need it yet.” No — when you DO need it, it’s almost certain that your needs will have changed and this thing you built months ago will need more hacking to shape it into a still barely workable solution.

“We shouldn’t interrupt development ‘flow’ to start on something totally different.”  No — ‘flow’ is not valuable by itself!  There’s no sense in building the wrong thing fast.

These all boil down to: I thought this was important -> If I admit that it isn’t, I will lose credibility and look like a flake.

And don’t do the weaselly version, either, where you silently lower the priority on tasks and hope people will forget about them.

Make an announcement: “We are no longer working on X.  Here’s why: we thought it was going to solve Problem Y, but [it actually won't/problem Y isn't actually much of a problem/it will, but problem Z came out of nowhere and we've got to tackle that.]  I’m sorry that we already invested time in this, but I’d rather change course than have us waste more time on something that is not needed.”

I say, flake proudly.  Don’t keep working on dumb stuff.

I started my career as a designer, so I find a particular irony in now being a vocal proponent of scrappy, get-it-done, ‘quick and dirty’ approaches.

But here’s how I reconcile it: “good enough” is not an acceptable end.  It’s a means to an end.  “Good enough” enables the pursuit of excellence.

I don’t know which workflow or messaging or feature is going to strike that perfect satisfaction within the user.  And neither do you.  (And don’t give me that ‘genius design’ argument – you are not Steve Jobs, and neither is anyone else except Steve Jobs.)

They are not the same things.

If I spent more time tweaking and revising, I would be happier.  But odds are, my customers wouldn’t.

So we start with “good enough”, and we watch and we learn.  And that’s how we know where to focus our tweaks or our ‘aw hell, scrap this whole thing and do it over’ attention.  And we do it again, and again, and again.  Good enough never is.. for long.

With KISSmetrics and KISSinsights both in pretty heavy usage, I’m seeing a lot of support emails and survey responses, and by far my favorite type start with:

“It seems like I should be able to do…”

These are great because they reveal customers’ expectations and the way someone is thinking about the problem that your product solves.

This is what comes next, after customer development interviews and getting a first version of the product out there – making sure the experience makes sense.  You lay the groundwork for this with your initial research, but you won’t get everything right on the first try.  Certain workflows will just feel awkward.  Certain features — which no one remembered before — will suddenly emerge as glaringly absent.

There are times when a customer says “It seems like I should be able to…” and you disagree: you had a reason to not do it that way.  That doesn’t mean you should capitulate to what the customer wants; it also doesn’t mean you should ignore them.

Why you need to understand expectation mismatches

It’s a good opportunity for you to say “We’re not doing it that way … and here’s why.” In my experience, that usually kicks off a really useful conversation that helps me better understand customer needs.  (or, yes, about 5% of the time it leads to people swearing and ranting -but that’s about par for the internet)

They may be masking underlying problems. People who “expect” a product to work one way may have very valid reasons why it can’t work your way — the new way requires access to files they don’t have, requires them to install software but they’re on locked-down corporate workstations, etc.

It’s a silent dealbreaker. If something is blatantly broken, customers won’t hesitate to let you know.  But if it’s just not-quite-right, most people won’t complain – they’ll just stop using your product.  They may think “oh, it must just be me…probably other people wouldn’t mind this” — in fact, I’ve heard plenty of people say exactly that in usability testing sessions before.

Getting more “It seems like I should be able to do…” feedback

Whenever it makes sense, I try to ask “What would you have expected?” or “What did you think you’d be able to do?” in reply to more general support questions.

Also: [SHAMELESS PLUG AHEAD] I use KISSinsights to try to “catch” this kind of feedback when I think a page is “not quite right” (or even/especially if I think it’s awesome).

(All 3 of these questions are available in the free plan.)