Dysfunctions of output-oriented software teams

September 17, 2019 :: 0 comments

When I see ineffective product teams, it almost always stems from a focus on delivering features instead of delivering value to people. From sales to marketing to product to engineering, they are more focused on output than they are on outcomes. They ask, "did we ship that feature" more than "did we and our customers achieve better outcomes?" No one asks if what the team is doing is really working.

John Cutler calls this a Feature Factory. Melissa Perri calls it the Build Trap. Whatever you call it, the symptom is that you’re measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.

An output-focused team doesn’t measure the actual impact of the work, doesn’t know what metrics are important, and can’t connect the product work to the whatever core metrics they actually do have.

Instead of metrics and objectives, they have deadlines and customer commitments. They can’t cut committed scope to meet these deadlines so they cut quality. They still miss the due date, and now have a product that is both bad and late. Other departments berate the developers for not providing more accurate estimates. No one ever asks why the word "estimate" means "commitment" in this team.

To fit things into the schedules and meet the estimates-turned-commitments, managers come in to assign and track tasks. The output-focused managers are more concerned with "resource utilization" as if the people building the product are machines. They don’t have well-integrated teams, leading to frequent handoffs between people, and siloing of knowledge and responsibility. Those handoffs lead to backups and gaps in the schedule, so they play team Tetris to try and keep developers busy, which makes the problems worse.

When an output focused team tries iterations, they defer important things to "later." Everything is pre-planned months in advance, they’re at full "resource allocation," and they’re always late with every iteration. So later never comes.

The managers try to fix all this by adding more top-down process, bogging down the teams. Things slow down, so the managers add more process to fix it and "hold engineers accountable."

How do you escape this method of working? Take small steps and look to continually improve. Start by defining success through outcomes and deciding up from what measurements will indicate you have reached those outcomes.

Accept that it’s OK if you aren’t always busy. Slack in the schedule is healthy and helps give time to explore and experiment. If you’re not focused on being busy all the time, you’ll be able to think more about creating a flow of value to the customer. Above all, empower people. Trust that the smart, capable people you’ve hired will do the right thing. Try managing through Commander’s Intent: define what success looks like, and then let them figure out how to get there.

Evaluative and generative product development

August 30, 2019 :: 0 comments

When planning a product, a common statement (normally from someone in a sales capacity) is “I haven’t talked to any customers that ask about X.” That may be true, but what about the potential customers that you aren’t talking to?

In the field of user experience there’s a concept of Evaluative vs Generative research. Evaluative is “which of these ideas that we already have are the best options?” Generative is “what are the ideas we have not thought of?”

The two approaches provide different outcomes. Neither outcome is better than the other, and both are usually needed to create a quality experience.

The needs of your customers and the overall market for your product can be thought of the same way. Entirely determining the product from evaluative customer feedback yields one sort of product. "Of the customers that are already finding us, what are their market needs?"

Think about when you go looking for a product to solve a problem for you. You do a sorting exercise and put products into "might do what I need" and "doesn’t fit my needs at all" as a first pass.

Customers never even talk to the companies that don’t fit their needs at all. If the only product ideas you’re considering are those that meet the needs of your current customers, then you’re only going to find new customers that look exactly like your current customers. You’ll completely miss out on adjacent customers.

To expand your market beyond your existing customer profile, you need generative product development. You need to explore product ideas outside of what you’re currently thinking of. Outside of what your existing customers are asking for.

A generative approach asks “what needs could we meet that would help new customers find us?”

Entirely using generative product creation isn’t a great idea unless you don’t have any existing customers. Your existing customers have needs and ideas and can be telling you which of the ideas you have now are most valuable.

Different stages of a product need different balances between generative and evaluative product creation. Mature products in a large market where sales are mostly driven by outbound sales and marketing will need a very different approach than a well-funded startup product that is still learning what their market is and can burn cash to learn. A company optimizing for short-term revenue will lean toward an evaluative approach, and one investing in future revenues will lean toward a generative approach.

But regardless of the way you’re leaning, you need to balance evaluative customer feedback with some generative product growth.

Product Manager Career Ladder

August 19, 2019 :: 0 comments

I was asked today what the various levels of product management are for someone who wants to move up the ladder. Here’s the way I see them. The responsibilities listed here are rough approximations for how it works at larger companies.Smaller companies will usually have only two or three levels, and the skills and responsibilities of each will bleed over between the different levels I describe here.

Similarly, the smaller the organization, the more likely you’ll see title inflation (or sometimes deflation). An example of this is when the only product manager is given a director title, despite acting more like an individual contributor.

The typical roles in a larger company are...

  • Associate product manager
  • Product manager
  • Senior product manager
  • Product Director
  • VP of Product
  • Chief Product Officer

Associate product manager

This is a junior position. Entry level, no experience needed, often right out of school. It’s not common at companies yet, but is really a training ground for new product managers. Pair with a senior, make them almost an assistant. This can be seen as an apprenticeship, and by following the Senior around and helping with tasks, they’ll learn how to be a product manager.

Product manager

Responsible for a feature or set of features, ensures that their products fit into the overall strategy for the larger product or product groups. Responsible for execution of their product. Tends to skew operationally, managing the project, handling metrics, sometimes focusing on P&L of their feature, if the feature has direct revenue ties.

Reports their metrics and status to the team for the overall product.

Senior product manager

Same as a product manager, but has more scope. Perhaps a larger set of features within the product. Or an entire product. Or a more complex feature. This is generally the end of the individual contributor line before moving into management. Tends to think a lot more strategically, but still needs to have good operational skills. New products, strategic shifts, and other projects full of unknowns go to the Senior Product Managers. Good ones are usually entrepreneurial, and are used to working with very little supervision or guidance.

Will often be responsible for managing the combined metrics and status of the various parts of the product, as reported by the product managers, although that’s sometimes a Director role.

Product Director

Manages the product managers. Owns the roadmap for a whole product or a significant chunk of the product. Possibly a small product portfolio of inter-related products. Focuses on a roadmap about one year out, and ensures that all the product managers are aligning their products and features with this roadmap.

Mentors and grows the product managers under them, and is responsible for creating and feeding an Associate program, if the company has one. Develops the processes and techniques used by the product organization.

VP of Product

Responsible for the strategy, vision, and long term success of an entire product line. Focuses on a roadmap and vision stretching multiple years ahead and possibly the entire lifecycle. Ties the company goals to the product vision. Aligns the product organization with the other departments. How do product processes meld with how product development works? What’s the strategy for taking the product to market? What sales channels will the products use? In most companies, this is where you top out in the Product career ladder.

Chief product officer (CPO)

Usually only found at larger companies or those with lots of product lines. And rarely at those, even. Like the Associate on the other end of this scale, this is a fairly new concept in companies and few companies have them. Connects the entire product portfolio to the company goals and plans. Manages the financial impact of product decisions, and how those decisions connect back to the company as a whole. Has financial, technical, and product skills.

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 »

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

  • Lock-in is bad T-Mobile thinks they'll get new Hotspot customers with exclusive content and locked-in devices.
  • The importance of being good Starbucks is pulling CD burning stations from their stores. That says something interesting about their brand.
  • Comment Spam Manifesto Spammers are hereby put on notice. Your comments are not welcome. If the purpose behind your comment is to advertise yourself, your Web site, or a product that you are affiliated with, that comment is spam and will not be tolerated. We will hit you where it hurts by attacking your source of income.
  • Where do the RSS ad startups fit in? Yahoo's RSS advertising service could spell trouble for pure-play RSS advertising services unless they adapt their business model.
  • 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.
  • More of the best »

Recently Read

Get More

Subscribe | Archives

Recently

Dysfunctions of output-oriented software teams (Sep 17)
Whatever you call it, the symptom is that you're measuring your progress by how much you build and deliver instead of measuring success by the amount of customer value you create.
Evaluative and generative product development (Aug 30)
Customers never even talk to the companies that don't fit their needs at all. If the only product ideas you're considering are those that meet the needs of your current customers, then you're only going to find new customers that look exactly like your current customers.
Product Manager Career Ladder (Aug 19)
What are the steps along the product management career path?
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

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.