Building the Customer-Informed Product

August 15, 2019 :: 0 comments

Customers should not lead your product development. Product managers that function by taking every feature request from the customer, turning them into product requirements, and working to deliver that feature are going to end up building a product that is disjointed and has no strength of vision. They’ll likely have very satisfied customers, but little growth and ability to scale. Instead of building what the market wants, they’re building what specific customers want.

We see this pattern in companies that build based on feature voting, and in companies that don’t have a strong opinion about what needs to be built. They act almost as a custom development shop, with some common components and maybe a common codebase, but with little feature usage overlap across customers.

Strong products are guided by strong visions, and the execution of that vision is the primary focus of product development.

This doesn’t mean that you shouldn’t listen to your customers. But your product roadmap should be customer-informed, not customer-led.

To understand the difference, imagine a seafood restaurant. They have customers come in periodically that don’t eat fish, so those customers ask for different food items. Some ask for salads. There’s some requests for steak. One weirdo wants a tofu burger topped with chocolate ice cream.

All these customers are willing to pay for their requested items, and often they’re willing to pay a lot more than you’d expect.

If the restaurant blindly implements every requested dish, they’ll lose their identity as a restaurant. They’re no longer a seafood restaurant, they’re an anything goes café that happens to serve a lot of fish. But their customers are telling them something important. They’re telling them they have needs that aren’t being met by the restaurant, and for whatever reason, they like the restaurant enough to want them to fill those needs, instead of just going to another restaurant.

What a reasonable restaurant would do is look at all these requests and see what adjustments they could make, for all customers, to fulfill the needs of these customers. They might decide to add a vegetarian option or two in the form of a salad or a pasta dish. If most of their requests were for various steak dishes, they may pick a single steak to offer on the menu.

This is being customer-informed. They’re letting the customers as a group influence the menu, but they’re not letting any one customer dictate the menu.

Assumptions and project planning

February 18, 2019 :: 0 comments

When your assumptions change, it’s reasonable that your project plans and needs change as well. But too many managers are afraid to go back and re-work a plan that they’ve already agreed to.

A manager received a large project that was crucial to the success of the company. Shortly thereafter all the managers then went through a company-wide planning exercise to determine staffing and budget needs for the coming year. He devised a budget and agreed to a plan with his managers and peers.

The manager felt confident in his projections and requests. Then, a few weeks later, once the team had started building the product features, he started to realize that there was a lot more work than he’d anticipated. He could still get the project done in the desired time frame, but he’d need more people to pull it off.

How to communicate this back to the company? You’ve agreed to a big plan and a budget, then a few short weeks later you come back and say you were wrong. Won’t that look like you’re bad at planning?

Especially in the early stages of a project, software development requires making a lot of assumptions. You think the existing production infrastructure will be enough. You expect a certain level of usage and strain on the system. You believe the algorithms you’ll need are like ones you built two years ago. The user authentication model will support this with only a few safe modifications. We can probably re-use most of the data model we created for the previous product. Your estimates for a budget, scope, and delivery dates all rest on these assumptions.

Once you actually start working on the project, you’re going to find out that your assumptions were wrong. Every time. But most of the time, the degree to which they are wrong isn’t a big deal. You might have even assumed something was a lot more complex and difficult than it turned out to be.

In this case, the team was integrating its software with various third-party systems. Because all the systems do roughly the same thing, it the team assumed that the implementation would be largely re-usable between vendors. This assumption was wrong. The result was that there was a tremendous amount of repetitive work required to implement each system. The team did not expect the amount of technical analysis, testing, debugging, monitoring, and general vendor management.

The assumptions were wrong, so the estimates and budgets were wrong. This is something that the company leadership should understand. The manager should go back to the company leaders and show the assumptions and the issues with them, then negotiate an increased budget, a reduced scope, or an extended timeline.

What a lot of managers will do instead is try and make the original plan work, even though the basis of the plan bad data. Rather than worry that you’ll look silly by raising issues so soon, realize that the rest of the company needs forewarning, not perfection. It’s better to give bad news now and avoid surprises than it is to give bad news later when it’s too late to do anything about it.

Feature voting is harmful to your product

February 7, 2019 :: 0 comments

Feature voting is the worst idea ever invented for product management.

"If I’d listened to what my customers asked for, I’d have built a faster horse." - Apocryphally attributed to Henry Ford.

When a company starts getting feature requests for their product, it often creates two questions. How do we keep track of all this and how do we know which requests are most important?

And thus the idea portal is born. Throw up a form and let customers put in what they want. Let them look through all the existing ideas and tell you which features they’d use as well. All at once, we’ve solved how to collect feature requests and how to know which we should work on first. Just sort by the top votes, and you’ll know what your customers really care about. There are even SaaS products you can use that manage the whole process for you.

What you’ve actually done is seriously damaged your product roadmap.

There’s a lot of problems with using feature voting to drive your product.

Read more »

Encouraging 1:1s from other managers in your organization

January 4, 2019 :: 0 comments

If you’re managing other managers, encourage them to hold their own 1:1s. At a minimum, doing them with their direct reports is non-negotiable. It’s such an important tool for managing and leading that everyone needs to be holding them.

I encourage, but don’t require, them to do skip levels and peer 1:1s, too. They’ll get huge benefits from seeing the bigger picture of the company, and you’ll find that managers are less threatened by you doing skip-levels with their reports if they’re doing skip levels of their own.

Most managers don’t do 1:1s well, and like everything else, it’s a learned skill. Teach them this skill.

Use your 1:1s with them to teach by example, and periodically ask them how their 1:1s are going. Dive deep into the problems they struggle with holding a 1:1.

Create templates for agendas, distribute ideas for how to get feedback, point them at blog posts like mine, and otherwise give them a starting point for learning their own effective 1:1 style.

If you have enough managers, invest in some training time with them. Teach them how to avoid falling into talking about the tactical day to day. Walk through what a 1:1 should look like. Have them practice on each other.

This is one of a series of posts about holding 1:1s. View the rest of the series.

One on One Meetings - a collection of posts about 1:1s

January 2, 2019 :: 0 comments

I’ve been blogging a lot recently about holding 1:1 meetings with your reports. Here’s the entire collection of these works.

One on One meetings for managers
A one on one meeting is one of the top ways you can build your managerial leverage
One on One meetings: Frequency and Duration
How long should your 1:1s be? How often should you run them?
Do you need a 1:1 if you’re regularly communicating with your team?
You’re simply not having deep meaningful conversation about the process of work in hallway conversations or in your chat apps.
What should you talk about in a 1:1?
Who sets the agenda? What should you discuss, and what should you avoid discussing?
What agenda items should a manager bring to a 1:1?
At least 80% of a 1:1 agenda should be driven by your report, but if you also to use this time to work on things with them, then you’ll have better meetings.
Handling “I don’t have anything to talk about” in your 1:1s
When someone says they have nothing to discuss, they’re almost always thinking too narrowly.
Are 1:1s confidential?
Is the discussion that occurs in a 1:1 confidential, even if no agreed in the meeting to keep it so?
Skip-level 1:1s are your hidden superpower
Holding 1:1s with peers and with people far below you on the reporting chain will open your eyes up to what’s really going on in your business.
Encouraging 1:1s from other managers in your organization
If you’re managing other managers, encourage them to hold their own 1:1s. It’s such an important tool for managing and leading that everyone needs to be holding them.

Are 1:1s confidential?

January 2, 2019 :: 0 comments

You’re having a 1:1 and someone brings something to you that feels like it needs addressing with someone else. Maybe they’re having a problem with a teammate. Maybe they’ve been approached about a new role. What do you do? Is the discussion confidential, even if they didn’t ask you to keep it so?

Mark Rabkin, VP Engineering and Product Facebook said, "If it’s safe enough to be overheard — it’s not the right content for a 1:1." The very idea of a 1:1 is to talk about things that shouldn’t be discussed in groups. Confidentiality is a requirement.

Skip-level 1:1s are almost always complaint sessions, often about their boss or teammates. You have to keep them 100% confidential. This is hard because it often feels like you need to fix things. You’re the manager after all, and what is your job there for if not to fix things? You must resist this urge. If the team doesn’t feel they can tell you things without it getting out, they will hold back, and you’ll miss out on the benefits of the skip levels.

If Carly tells you she’s thinking of applying for a spot somewhere else in the company, you can’t go tell her boss about it or your trust is blown and the skip levels become useless.

You often have to avoid taking direct action after a 1:1, so you don’t inadvertently leak what was talked about. Evan tells you that his boss is taking forever to approve the latest plans, you’ll have to wait a while to talk about it with his boss, or he’ll think Evan tattled on him.

In 1:1s with your own reports, they’re talking to their boss, so they have an absolute expectation of privacy. Unless you specifically talk to them about bringing someone else into the discussion, their thoughts and concerns should stay completely between the two of you. If you find that you’re regularly talking bringing something up with someone else, then you either have a seriously dysfunctional company, or you’re talking about the wrong things in your 1:1s (hint: stop talking about the work you’re doing).

Of course, if something illegal or unethical is going on, address it right away. Take whatever steps you can to sanitize the source, but you can’t allow bad behavior to continue.

This is one of a series of posts about holding 1:1s. View the rest of the series.

This can’t be good: http://t.co/vJCJ3D2g Jun 21, 2012 10 :07 via Twitter

Am I the only one wondering what would happen if I unplugged that Ethernet cable? Jun 19, 2012 11 :03 via Twitter

Now I know why my hotel wifi signal is so good: http://t.co/ADAKVtPK Jun 19, 2012 11 :01 via Twitter

The Oakland A’s are selling root beer floats to raise money to fight diabetes. Next month, how about beer proceeds donated to AA? Jun 18, 2012 12 :17 via Twitter

Dear gmail, please sort autocomplete contacts by frequency of use. I email my wife Christina way more than I do @ChrisPirillo. Put her 1st. Jun 17, 2012 7 :42 via Twitter

My son’s school is selling or giving my contact info to local businesses. Lovely. Jun 16, 2012 9 :25 via Twitter

Two iPhones in the house took a swim this week. Opened them up, cleaned them out, they’re both working again. Jun 15, 2012 7 :38 via Twitter

If your pitch deck is more about the animations than the company, you’ve already lost. Jun 15, 2012 3 :36 via Twitter

The ER is always filled with interesting people. Jun 14, 2012 10 :04 via Twitter

Proof reading is gud. Jun 14, 2012 6 :31 via Twitter

Follow me on Twitter

Best Of

  • Simplified Form Errors One of the most frustrating experiences on the Web is filling out forms. When mistakes are made, the user is often left guessing what they need to correct. We've taken an approach that shows the user in no uncertain terms what needs to be fixed.
  • Pitching Bloggers Forget what you learned in your PR classes. Start acting like a human instead of a marketer, and the humans behind the blogs will respond.
  • How not to apply for a job Applying for a job isn't that hard, but it does take some minimal effort and common sense.
  • Embrace the medium The Web is different than print, television, or any other medium. To be successful, designers must embrace those differences.
  • Newly Digital Newly Digital is an experimental writing project. I've asked 11 people to write about their early experiences with computing technology and post their essays on their weblogs. So go read, enjoy, and then contribute. This collection is open to you. Write up your own story, and then let the world know about it.
  • More of the best »

Recently Read

Get More

Subscribe | Archives

Recently

Building the Customer-Informed Product (Aug 15)
Strong products aren't composed of a list of features dictated by customers. They are guided by strong visions, and the execution of that vision is the primary focus of product development.
Assumptions and project planning (Feb 18)
When your assumptions change, it's reasonable that your project plans and needs change as well. But too many managers are afraid to go back and re-work a plan that they've already agreed to.
Feature voting is harmful to your product (Feb 7)
There's a lot of problems with using feature voting to drive your product.
Encouraging 1:1s from other managers in your organization (Jan 4)
If you’re managing other managers, encourage them to hold their own 1:1s. It’s such an important tool for managing and leading that everyone needs to be holding them.
One on One Meetings - a collection of posts about 1:1s (Jan 2)
A collection of all my writing on 1:1s
Are 1:1s confidential? (Jan 2)
Is the discussion that occurs in a 1:1 confidential, even if no agreed in the meeting to keep it so?
Skip-level 1:1s are your hidden superpower (Jan 1)
Holding 1:1s with peers and with people far below you on the reporting chain will open your eyes up to what’s really going on in your business.
Do you need a 1:1 if you’re regularly communicating with your team? (Dec 28)
You’re simply not having deep meaningful conversation about the process of work in hallway conversations or in your chat apps.

Subscribe to this site's feed.

Contact

Adam Kalsey

Mobile: 916.600.2497

Email: adam AT kalsey.com

Twitter, etc: akalsey

Resume

PGP Key

©1999-2019 Adam Kalsey.