Executives in corporate environments have one of three belief systems about software development. To build successful products it is essential for product managers to understand what belief system their executive team subscribes to.

• Belief system #1: We have to build these features and they have to be live by this date.
• Belief system #2: We have to be live by this date — what features can you get done by then?
• Belief system #3: We have to release these features next — how long will it take to get that done?

Belief system #1 is the most common, and it is poison. It usually goes along with a distorted Steve Jobs “reality distortion field” complex, and the only thing it produces is crappy software and burnt-out teams who feel distrusted and undervalued. A product manager’s first job is to move the executive team away from belief system #1.

Belief system #3 is the ideal scenario for most large corporations¹. Software development and the product manager’s role are usually well understood in such environments. The product team gets to present their market-driven ideas to the executive team, who can focus on what they do best: providing perspective, vision, and assistance with prioritization. This allows product teams to set their own schedules based on what everyone agrees needs to be done as they balance what’s best for users, the business, and the technology.

Belief system #2 is not ideal, but it is certainly better than #1, and I’ve learned that it is impossible to move executive teams from belief system #1 to belief system #3 without the interim step of belief system #2. The logical jump from #1 to #2 is easier to influence since product managers only have to deal with one variable: the constraints of time.

If a release date is fixed² product managers shouldn’t spend time trying to move out the date to accomplish everything the executive team wants them to. Instead, spend time explaining that the release date is a horizontal line. All features above the line gets done by the date, and all features below the line don’t, and will have to wait for a future release. Explain that the development team can only do a limited number of things in a given time frame, and if some feature suddenly becomes a must-have, one of the other features have to move “below the line”.

This might seem like a trivial concept, but that’s because we’re software people. Most executive teams have a really difficult time with this because software development in agile environments is fairly new to them.

It bears repeating that one of the biggest mistakes a product manager can make is to try to change people’s belief systems from #1 to #3 without first taking them through the logic of #2. That said, once a project has been completed successfully using #2, the shift to #3 is usually fairly easy to make. That’s because the executive team had the opportunity to get a glimpse of how much better the software can be if “required” features aren’t shoved down a funnel that cannot withstand the pressure.

If you work in a large corporation, identify your executive team’s software development belief system, then guide them to #3. Your product, your business, and your team’s morale will be better for it.