Going from sales engineering to product management  was a jarring transition at first, because it represented a change in tempo. As a sales engineer, I lived by the fiscal quarter. While a given customer might be a multi-quarter job to convert, my sales partners and I had money to make and were judged on a quarterly basis. Our bread and butter was the quarterly cycle of identifying opportunities and closing them. I wrote software to help my customers and learned some lessons that way, but the jump to product management in enterprise development organizations still surprised me.

Shock number one: resourcing. From the field, you can see numbers like the allocation of headcount to engineering, and you can easily imagine that there are dozens of people working on a product. From the factory, you’re more aware that a team of dozens is rare, and a given product probably has one to six actual humans working on it — if you’re lucky. A platform company can do an amazing amount of value creation with small teams, but they can’t do everything.

Shock number two: here comes the flood. All products have an incoming stream of tickets. Customers and partners have support requests, bug reports, and feature enhancement asks. Maybe it’s a small trickle, but if the product is successful, there’s at least dozens a day, maybe hundreds. You can try to offload it on someone else, but rigorous process is the only effective answer in my opinion. As a field engineer it can seem that a good idea is its own justification. As a PM, that good idea is only a starting point.

Shock number three: tempo. As the title of this post indicates, product time scales are very different from sales time scales. As a field engineer making free software, development feels fast. You write some stuff, it works in your lab, you post it for some friendly users, iteration chugs along as fast as you can go. As an R&D scrum team the process is much slower. You have more platforms to support. You can’t rely on some software licenses. You have to think about adversarial use cases and product security. You have to coordinate your activity with the rest of your team in order to build sustainable and supportable software. Bug fixes can go pretty quick, but as a rule of thumb, adding a meaningful feature takes a quarter. Adding a minor feature takes at least a month.

Here’s some advice for sales engineers and similar field characters — of course you’ve probably heard it before, summarized as “Sell what’s on the truck.”

• If you’re expecting a product change to save your deal you’re making an account management mistake. “Sell the sizzle not the steak” is about making your product look good, not about building a deal on dreams.
• Shipping product is for dinner, roadmaps are for dessert. The roadmap’s function is to demonstrate that the company is still investing in this product, not to establish a schedule of future feature deliveries.
• Those said, there is a counterpoint: If you don’t sell it, it will never be fixed. Selling the products is essential to the success of a software company, and if customers don’t use the products then they won’t sell very well. Without sales there’s no one validating features work, no one finding problems, and no reason to fix what’s already known to be suboptimal. So you’ve got to have faith that what the factory says will work can be made to work.

Followed by advice for product managers coming from the field, which you may have heard as Eisenhower’s quote: “In preparing for battle I have always found that plans are useless, but planning is indispensable.”

• Your tempo has changed, not your activity. Where you were preparing a customer to buy or renew a product (quarterly tempo), you are now preparing the company to invest or maintain investment in that product (yearly tempo).
• Your scale has changed, not your motivation. Where you were helping a customer to use the product successfully, you’re now helping all customers. Where you were helping a friend with their deal, you’re now enabling the entire field to position your product correctly. Where you were convincing a product leader to prioritize a bug fix, you’re now convincing an engineering leader to allocate person hours.
• The future is an unknown country. There are only three time buckets that matter.
  • The present has what you’ve recently shipped and the things that engineers are working on now. There is a good chance it will work.
  • There is what you want to do next, which you’re currently designing with your engineering counterparts. There’s a 50/50 chance this will eventually ship.
  • Everything else is in the backlog and does not matter. You can draw a pretty picture of a roadmap with releases for that stuff, but it’s fiction. Its purpose is to build excitement and set up resourcing for next year.

Summarizing, watch out for this offset in tempos, because it can cause inaccurate expectations.

• It takes a quarter for enterprise software product changes to affect sales numbers, because smart field people won’t sell it until it exists.
• It takes a quarter to deliver a change to an existing product because teams of engineers have to build sustainably. So if you have to make product changes with existing engineer allocations to affect this year’s numbers and you’re just planning them at the end of Q1,  you’re going to deliver them in Q3 and you’ve got all your eggs in Q4. This is half of why most B2B companies have most of their revenue in their fourth quarter (the other half is bluebird deals from customers with use-it-or-lose-it budget cycles).
• Whatever plan you offer for making new product without allocated engineers is setting up for next year’s sales at best, assuming you convince leadership to rob an existing product or hire new engineers starting now.
• SaaS doesn’t change those dynamics as much as people might assume that it does, but it does help to smooth out a spiky cash flow.
• Acquiring a company instead of building software provides a faster bump to your sales numbers because you can just claim the new company’s numbers as part of your own; but it also hurts your ability to deliver software later on.