Category: SteveJ

Feeding the product team using “pull”

As soon as somebody says you’re spending too much time on something, you’re on the right track.—Bob Lefsetz, American music industry author.


There are two approaches to delivering stories to your product team: pull and push. Typically, product managers and executives “push” more and more requests to the developers. Even though the team already has a bunch of things, we push another few and then another few and then some more until the team is paralyzed with unfinished work. In more practical terms, the product manager builds a long list of prioritized requirements, perhaps grouping them into themes or releases, and sends the developers a few hundred items at a time. This is probably the most common scenario and tends to have three negative effects.

First, a long list of stories is overwhelming to the team, which damages their spirit and hurts productivity. Second, this approach tends to give you a whole bunch of disconnected stories so you have 80% of everything but not 100% of anything. Finally, pushing a lot of work at one time means you can’t reasonably re-prioritize the work when business conditions change.

Rather than pushing a bunch of work to developers, I prefer to let them “pull” work when they’re available to take on new tasks. In this scenario, the product manager maintains a long list of prioritized work. Developers request more work when they have bandwidth and the product manager hands them the next thing on the prioritized list.

One of the chief ideas of Kanban is to limit the amount of work in progress. Each developer works on one item at a time. They work until they’re done and then ask for more work. The product manager maintains a steady queue of work in queue.


Since the product manager is constantly prioritizing the list, the most important items are always on the top of the queue, waiting for development bandwidth.

Task switching is a well-known detriment to productivity. You want to avoid changing the work that has begun. Never mess with work-in-progress. But since no work is being done on your story queue, you can always add items to the top, bottom or the middle based on their importance.

In one product management job, I was told the development team was terrible; they couldn’t seem to finish anything. Investigating further, I found the problem wasn’t with the developers but with the executives. They were changing the priorities constantly. They didn’t seem to realize that one sentence from the leadership team meant weeks (or months) of work for the product team. I found the developers to be quite competent but with an ever-changing priority list, they couldn’t complete anything before a new #1 priority interfered.

We switched the team from a push approach to a pull technique. We didn’t mess with anything that was in progress. All new ideas went into the product manager’s queue, was prioritized based on business value, and then delivered to development when they needed work. That meant that executive pet projects could be put on the stack and then delivered to the team when the item became a top priority.

It also meant that bugs and architectural stories could be delivered to development just like requests for new functionality.

And when you’re working in short cycles, new important items can be started every week or so. It’s not like we have to wait a month or a quarter to begin a new initiative.

Are you using a “pull” method with your team? Share what’s working in the comments.

Why you need an innovation team

By Steve Johnson

Every organization has to prepare for the abandonment of everything it does.

—Peter F. Drucker, American management consultant.


How does a pack of wolves take down a bear? They attack from all sides. While the bear is dealing with a frontal attack, another wolf is attacking from behind. Ultimately, the bear gets exhausted from turning and turning and turning to address each attack.

Sound familiar?

Maybe you’re the biggest vendor in your space but you’re being attacked by upstarts. After all, with today’s technology, a new player can go from idea to execution in weeks—less time than it takes for you to get a business plan defined and approved.

Maybe you’re the biggest vendor in your space but you have more ideas than you can execute. And as soon as you decide on a set of priorities, a big sale or executive pet project comes in that de-rails the plan.

To survive attacks from too many internal ideas and too many external threats, you need a nimble planning process to move (quickly) from idea to execution. You need to evaluate a new idea, test your hypotheses, and come up with a plan—before your competitors do.

That’s why I recommend an internal innovation team. A team dedicated to a single product idea. A team without a thousand meetings and phone calls and emails related to existing products. A team that is able to ignore “what is” in favor of what could be. Should you deliver via the cloud? Should you do a subscription? Should you sell over the web? Just because your company hasn’t in the past doesn’t mean you can’t in the future.

You can build a business concept and deliver it to market in only 90 days.Who is on the team? A business expert, a market expert, and a technology expert. (Notice I didn’t use titles here. The key is not the title but the expertise.)

And how responsive could this team be if it didn’t have to train everyone in the sales and marketing and support and services teams? Instead you build a small launch team focused on a small group of representative customers.

With a small team of experts, you can build a business concept and deliver it to market in only 90 days. It’s possible! After all, it’s what your competitors are doing.

Interested in the types of expertise in product management? Read my free ebook “Expertise in Product Management.”

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

Top-down prioritizing: markets and portfolios

By Steve Johnson

Failing to focus, failing to choose one discipline and stick to it, is exactly what leads firms to a state of mediocrity.—Michael Treacy & Fred Wiersema, authors, Discipline of Market Leaders

In most organizations, development teams have dramatically less capacity than the appetites of the business units and sales teams. That’s why I continue to hear things like “how can we get the developers to work harder?” or “why aren’t they giving me what I need?”

The big thing is this: you only get the development your organization has chosen to afford. [tweet this]

Many cannot understand why this feature or that one can’t simply be added to the list. Here’s why: adding a feature means moving or deleting another feature; satisfying one customer (and their sales person) usually means disappointing another customer (and their sales person).

Product marketing or market owners should focus on a market full of customers, and generate a prioritized list of what is needed by their markets; portfolio owners should direct those market stories to the appropriate product. And company leadership prioritizes these with the budget.

To do this successfully, your leadership needs to do two things: allocate investment by market and then by portfolio.

Allocate investment by market

Allocation of development spend reveals your market strategy and provides guidance throughout the organization. In practice, this means approving or revising the recommendations made by the product marketing and product management teams. It means signing off on a portfolio strategy for products and sticking with the strategy in each part of the business.


Allocation of development spend by market sends a clear signal of the company’s priorities. For instance, perhaps education is your top priority, then health, then Europe. Allocation by market ensures that each market gets funded in sync with the overall business strategy. If your #3 market priority is Europe, this market will still get funding for their requirements (although perhaps not as much as they want) instead of just hoping to get some of the other markets’ funding.

Allocate investment by portfolio

Perhaps some of an organization’s frustration occurs when executives cannot see or do not understand how product trade-offs are made today. In a company with multiple products in varying stages of their lifecycle, leadership must decide where to put their investment dollars. This top-down approach reveals the relative importance of each product in the portfolio. Once the decision is made for levels of funding, the product management team can show what features can be delivered for the allocated budget.

If you allocate dollars for development in one product, product management can tell you what you will (and will not) get for that money.

Product management can help focus the allocation by clearly articulating the portfolio positioning. One product is for this market; another is for that market. The portfolio positioning must be enforced companywide; we cannot allow sales people to sell products outside their intended markets—and if they do anyway, it means rejecting those contracts.

The Three Horizons model (advocated by Clayton Christensen, Geoff Moore, and others) reminds us to redirect profits from old products to fund development of new products. It means the older products don’t get all the development spend they may want because their profits are paying for innovation in future products. I know that many product teams are frustrated when they don’t get the funding they want but we’re trying to run a company, not just a product.

Remember, if we only focus on this year’s revenues, we’ll have last year’s best product. [tweet this]

I recommend an allocation that includes, for each product release, something that will appeal to new buyers, something for existing customers, something that furthers your vision, and something that upgrades your infrastructure. (See more on this at Politics and your next release)

And don’t forget services! We need to extend the view of “product” to include services and support in addition to software and hardware. After all, your customers buy a solution that is often much more than the product. In future, services should be defined (by product management) and promoted (by product marketing) as clearly as your products.

Take the example of the Nest Thermostat. It comes with all the tools and instructions necessary to install it but they can arrange for your installation if you aren’t comfortable installing it yourself. Nest also sends an email periodically reporting your power consumption (and reminding you how much you’re benefiting from their product).

Within the portfolio, given a total dollar amount of funding, you then allocate the development funding to the products.


Look to your current spending on the product. How much is spent on maintaining code and fixing defects versus adding new functionality today? Let’s assume you’ll spend the same next year. And let’s also add some amount, like 10-15%, for innovation or other internal improvements.

The challenge you’re likely to face is the market owners and sales people and others may want to allocate all the funding to new functionality but we also have to account for maintenance, defects, and innovation. If you want to change these allocations, you’ll need to be able to explain why this year will be different from last year—new techniques, new priorities, new team members may indeed justify changing your previous allocations.

Next steps

I used to work for a company that generated 15% of their revenues from one product. Because of this, the president said he didn’t focus much on the product—he never spent more than 15% of his effort on it. However, if the product currently generates 15% but could generate more, you’ll need to convince your leadership why they should allocate more attention and funding to this emerging product.

Market and portfolio allocations can be estimated by product marketing (or market owners) and product management (or business owners) respectively and presented to the leadership team for revision and approval.

Your company leaders signal their top priorities with funding. They can tell us the relevant importance of specific markets and products by showing the percentage of money allocated to each.

Need help prioritizing your portfolio? Make it part of your product playbook.


About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

Politics and your next release

by Steve Johnson

A desire not to butt into other people’s business is at least eighty percent of all human ‘wisdom’… and the other twenty percent isn’t very important.—Robert A. Heinlein, author

You’ve planned a new release, pulling together ideas from the market and from the company. You think you’ve got a really strong plan but as soon as it’s announced, the complaining begins. “Where’s my pet project?” “When are we going to fix security?” “But I promised this feature to a prospect!” “Waa waa waa!”

Never forget, a product release is always political. To be successful, every release needs something to appease each of your internal stakeholders.


Now I know many product managers want each release to be purely focused on the needs of the market but prioritization inherently has a political aspect. Prioritizing explicitly says one thing is more important than another. Someone is going to be disappointed since there are so many who want their idea at the top of your list. After all, there are many folks in your company who think they know exactly what the product should be.

Here’s one solution.

Every product release should contain at least one big thing for each of the product stakeholders.

  • Strategic feature: one that aligns your company vision or portfolio strategy
  • Buyer-oriented feature: a new capability that appeals to buyers (and their sales people).
  • User-oriented feature: one that improves the usability or adds a new capability. After all, people who pay maintenance or monthly fees expect some of their money to go to new stuff, not just for support.
  • Architectural feature: one that makes the product easier to maintain for our internal teams. Sometimes this is about fixing clumsy code or improving security or reducing some annoying defects. Or adding capabilities and diagnostics to make the product easier to implement, service, or support.

(Ideally one or more features would also mess with the competition.)

These four items are the ones you emphasize in your roadmap and your internal communication.

4 features

One development team said they needed nine months to fix all sorts of internals and address years of technical debt. But rather than just “going dark” for a year, the product manager blocked out the major areas that needed to be addressed and roadmapped them. They allocated time and money for new stuff as well as the internals. They met the internal needs and also their political needs.

One thing for vision (and for executives), one for buyers (and sales people), one for customers (and your support organization), and one for maintenance (and development). It’s a good release.

One of my favorite sayings is, “Nothing seems hard to people who don’t do it.” [Tweet this]

Prioritizing is one of these. One sentence from an executive results in months of work for the product team. Not every idea can be the number one priority. Build a release plan that has something for each of your major stakeholders and you’ll get better buy-in to your plan.

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.

UX and product managers


On the Mind the Product blog, Martin Eriksson writes,

I’ve always defined product management as the intersection between business, technology and user experience. A good product manager must be experienced in at least one, passionate about all three, and conversant with practitioners in all.

To Martin’s list I would add expertise on the market (or persona) and a passion for the domain. I’ve written about expertise in product management in my free ebook. (Download it here).


User experience (UX) is an area that befuddles many product managers. Ideally, product managers should be focused on the customer problem while development designs the company’s solution. A strong dev team will propose one or more solutions to the articulated problem, allowing the product manager to accept the best option by leveraging his or her business, technical, marketing, and domain knowledge. A UX designer is a critical element of a successful product team.

If you’re interested in UX design (and all product managers should be), take a look at The User Experience Guidebook for Product Managers from the helpful folks at UXPin.

The difference between good and great is often in the user experience. Let’s all become passionate about brilliant UX design.

About the author

Steve Johnson is a recognized thought leader and storyteller within the technology product management community. At Under10 Consulting, he helps product teams implement product management in an agile world. Sign up for his inspirational newsletter.