Saturday, September 17, 2022

How to Run an Customer Roadmap Call

What is your goal? Depends on the stage of the company… you might be working with a five year roadmap of value extraction activities, but if so I can’t really help. I’ve always left companies when they hit that stage. What I’m much more used to is active value creation. That will translate to a six to twelve month roadmap of what we’re doing now and what we’re thinking about doing next. This kind of roadmap is a conversation, not a schedule.

Before you do anything else, prepare your note taking system. Your goal is to acquire knowledge of your customer’s needs, and the best way to serve your team is to get it in writing.

Step one is to prepare with the sales team: get fifteen to thirty minutes with the account manager (might be called an executive or representative), technical representative (might be called a sales engineer or TAM or CSM), and project manager if there is one.

  • Does the customer realize that we’re not giving five year projections? This isn’t a blatant question, but something to listen for in your conversation. There are vendors who are working to a very long term plan, and there are other vendors who pretend to be… if you’ve hired account managers from either, their expectations may not be aligned with the more discovery-driven approach of a small and agile enterprise software vendor.
  • What do they want to hear about? Product they own? Product they’ve heard about? A competitive product they’re interested in dumping? A recent problem they need to solve?
  • What hot buttons should you be aware of? Bugs, of the production impacting or annoying variety? Personnel changes? New partnerships or competitors?
  • Who’ll be on, what are their roles, and do they like to talk or not? The worst roadmaps are you talking to dead air. If the customer won’t engage, might as well play them a recording or send them a PDF of your deck.

You’re the voice of the company presenting on the future; let sales guide, but watch out for common traps like the unattainable goal or the revenue recognition blocker. Not every account manager can recognize when they’re in these traps, and you might just save them (and everyone else) a lot of pain.

Discuss the company’s goal and strategy (in terms of value delivery, goals like leadership quadrant positioning are expected to come from that naturally). This slide is usually a geometric metaphor for what you build. A platform with capabilities on it? An ecosystem in which you provide specific features? An exponentially improving workflow that you make possible? Something like that.

Discuss how those goals inform features. This slide is your top three focus areas, icons backed with two to four words each. What are you doing this year? A partner ecosystem? A UX refresh? This would be the stuff your executives talk to your board about, not specific features or specific products.  

Stop and ask if you’re on the right track. Give them time to unmute. If you get a monosyllabic answer, this call is probably not going to get you anything valuable, so you can probably speed up.

Cover recent deliveries first — most customers weren’t paying attention to the things you thought were dreadfully important.

Then focus on your current top line deliverables, the most important things you’re working on. You know you’re pretty likely to actually deliver them after all.

By now, if a customer is engaged they will have commented or asked a question. If you haven’t heard anyone else talk, stop and ask a question. “Would that feature be useful to you?” “I forget, do you use us for that today?” “Have you got any Grey Poupon?” If you still can’t get any engagement, you might just be dealing with a cultural difference, or you might be dealing with a customer who doesn’t want to share any details. Whichever it is, there’s no winning by trying to drag words out of them — you might get lucky and inspire conversation, or might just as well create bad feelings or friction. If there’s still no engagement at this point, I’ll skip any remaining slides and go the the end.

The end of the deck is blue sky ideas. This is the stuff that you’d like to do but haven’t got clear plans for; adjacent markets, new tech, moonshots. Talk about your favorite one or two, then ask if there was anything the customer missed or expected you to touch on. An engaged customer might go into a new idea, or they might want to talk about bugs in a product they’ve got, or they might want to talk about your competitive situations. 

Time’s up, if the account manager hasn’t already taken the talking stick back, hand it off. The customer may ask if they can have your slides; that depends on your company’s culture, so make sure you know the answer before you get on the call. If you’re responsible for that answer… there’s two major risk paths to consider. One is that your own people will do their own variations on the roadmap presentation. As companies scale, the PM team invariably grows more slowly than the field does, and it can be difficult to get calls scheduled. It’s not uncommon for authorized or unauthorized roadmap calls to get delivered, and maybe even edited to tell customers what they want to hear. While that’s hardly ideal… it’s also not something you can personally stop. Second, anything you hand out has a chance of ending up in a competitor’s hands, who frankly probably won’t care. The competitors that you should worry about are too heads down on their own work to spend time worrying about yours. All that said, the default position should be not to share the roadmap deck. Keep it separate from your field team’s deck, and if you do share with the customer, make a copy watermarked with the customer and date and PDF that for them.

Final step: while the account team is wrapping things up or maybe during the first few minutes of your next meeting, you need to review your notes, fill them in with anything important that didn’t get written down, and then share them to the team. Maybe that’s entering them into a system, maybe it’s a shared document you maintain, maybe it’s just a Slack room, but get this material off your laptop and into the company’s shared domain before your attention moves to the next problem.

Sunday, August 14, 2022

Building The Habitual Year

 As a new Product Manager, you’ve got a huge increase of demands on your time. You’re now the person responsible for answers about the product, and if you’re selling it globally or developing it overseas, that means you’ve now got a never-ending day. Additionally, it’s not just those tactical questions of “does it compete with Foo” or “can we prioritize Bar”… you’re on the hook for a strategic plan as well. Quick, how does this product serve your company’s goals, have you fixed bug number 8675309, and what’s your projection of outcomes if we OEMed an adjacent feature and bundled it?

Don’t despair though, there are ways to handle the load and thrive. The key is to understand the tempo of product development, and use processes to ride that tempo. Use your calendar to make time. When things need to be done and you don’t have time or materials to do them right now… put time onto your calendar right now. Think it will take three hours for that task? Why not block two blocks of three hours next week. Think it will take ten minutes? Block thirty. Know that you have to do a series of tasks over a month? Schedule the blocks where you’ll do them, and explain that schedule in writing to the stakeholders who are waiting on those tasks.

Next, think about which processes need to be done. From the outside in:

  • You need to have a goal, and a vision for exactly how your products are going to help that goal. You might not be the person responsible for doing that or making it make sense, but you need to know that you're heading North instead of West.
  • You need to have a plan for sales and marketing and a plan for R&D. You might not be responsible for delivery and execution of either, or you might be closely involved in one or the other or both... but you need to know that someone is taking care of these plans.
  • You need to do tactical work to complete the product plan and achieve the company's goal
  • You need to assess your PM load and discuss with your leadership if you need help or can give help.

Luckily, all that easily translates to calendar items… some more flexible than others. It’s not like you need to set the hours you’ll spend on Q4 planning before you can proceed with your January, but it does help to realize that halfway through Q3 you will be spending a week on Q4 planning. You’ll also spend a week on your sales kickoff in Q1, and a week on your customer conference in Q4. Are there industry conferences you need to be at? Get them in your plan. 

The rest of your calendar fills in with three types of meetings (in order of importance): customer calls, standing meetings, and one-on-ones. This stuff will expand to fill all gaps, so here’s three bits of advice:

  • set your working hours, transit times, and meal times — and then defend them
  • take vacations. When you take a vacation, disconnect from work. When you plan a vacation, delete what you can, delegate what’s left, and reschedule what has to be done by you.
  • Leave any meeting that is not adding value (at the least by tuning out, but dropping is good too)

This flood of activity can be hard to keep track of, but luckily there is a process tool for that as well… set a block of time to reflect on what happened every week. 

One last thing… what I’ve just described is a plan, and plans don’t always survive reality. When reality intrudes and disrupts this plan, look back on all the things that didn’t get done. Are they still necessary? If so, reschedule them because they still have to be done. If the new reality has obviated those tasks, congratulations — you get to delete some items.

Saturday, August 13, 2022

How to Run a Standing Team Call

A standing team call is any call where a group of people meet regularly.  Every time you notice that it’s coming up, try to take a few minutes to do these things:

Figure out what type of call it is, then ask, does this call still need to exist? Some possible answers:

  • The call provides a status update. Well, couldn’t that be done asynchronously? There are definitely cases where asynchronous is effective, but if you have important information to share you might need a standing synchronous opportunity in addition.
  • The call provides a decision forum. Well, couldn’t that be done asynchronously? Maybe a lot of things are getting done that way, but it’s still helpful to have a place where the decision is Made and Communicated, so that it doesn’t float in limbo.
  • The call provides a social forum for people to work together. This is critical in a distributed team; water-cooler video chats are great, paired programming sessions work, but structured whole team time for triage and status sharing is where the team-formation-and-maintenance rubber meets the road. 
  • The call has always been there. Like Chesterton’s Fence, it was set up before any of us got here and we’ve just kept it going. Maybe the CEO asked for this but no longer has time to attend? Maybe it’s a social forum for leaders who rarely interact? Every re-org or change of management is an opportunity to revisit the calendar. A much-welcomed power move is to review standing meetings with overlapping personnel and consolidate them into a single meeting. 

If you can’t come up with an answer for why this meeting exists in your own head, ask the attendees. Maybe they’re heartily sick of this call. Maybe they think it’s important. Get information. 

If the call remains useful, proceed.

Review the call materials and invitees. I find my most productive status update calls are done by openly reviewing a document that I’ve already prepared or had a direct report prepare. Any gaps in my knowledge are corrected in realtime in front of our stakeholders. Any questions from stakeholders are captured in that document and answered later if we can’t answer them there. Do your call materials allow that? Are they editable by the right people so that your team can help you prepare? Are they readable by the right people so that stakeholders who can’t attend could asynchronously review? Are you all still getting value from the log that this material represents? Standing meetings generally exist in response to trauma, is this one working to reduce or prevent traumatic events? Do new team members know why it's there and what's appropriate to discuss? Do new stakeholders have an invite?

Run the call. You are the emcee, and this is your show. Get it done snappily. Use humor if you’re able to do so safely, but be aware that clever can fail badly. Be energetic, honest, clear, and above all concise. The written materials can provide detail and link to resources, you’re just here to encourage people to talk about their project status. Call them out, gently shut them down if they go into too much detail, and summarize what they said verbally and in the written materials. When you call on someone, watch their status icons. If they’re struggling to unmute, acknowledge that… if it’s a pattern, maybe note in your next one on one that this is a call where participants are expected to be on the ball and get the communication done crisply. Don’t let anyone drone on for several minutes, any meeting’s hold on a group of people is tenuous to begin with.

Praise in public, criticize in private. If team members are doing well, call them out. If they aren’t, schedule a 1:1 or 2:1 with their manager to discuss your concern. Enforce this standard with your stakeholders as well; if someone wants to complain that your work for them is running late, tell them you’ll take this conversation offline. If someone brings up a surprise for you, note it and move on. You're not here to get answers, you're here to find questions.

Watch the clock. Start it as soon after the scheduled time as you can, and wrap it up as quickly as you can smoothly achieve. Some socialization is fine if you’ve got a “one-pizza” team. Two pizzas on the call, it’s time to be a little strict. More people than that, they don’t want to hear about anyone’s vacation. Use a stopwatch app if you need, and publicly acknowledge as a team success if you’ve ended the call early. You’re here to get the objective of the synchronous call done as fast as possible. If you book thirty minutes for a call and get it done in ten, no one is going to be sad about that. If you do that regularly, you'll get more attendees.

That said, at the end of the call be sure to open it up. I like to use specific catch phrases like “open floor, any questions or issues from the team?” In a standing call, that rhythm and predictability helps the half-listening realize that this is their time to talk. Give them thirty seconds to get off mute, then wrap it up.

If the meeting is to be recorded, make sure you click record before you start and post the recording to the location where it belongs before the day ends.

Make sure that the location of materials (written notes, resource links, recording storage, metrics dashboards, &c) is in the calendar invite.

Mission Statements


A good mission statement is an aspirational goal that helps everyone move in roughly the correct direction. 

It is not strictly descriptive of what the organization is currently like, but it should reflect the best moments attained. An aspiration that is not grounded in the possible is easily ignored, or worse yet leads to folly.

It should be short. “The bandwidth for communication in a large organization is about six words”, says @clintsharp, meaning you can’t get complex ideas from top to bottom or side to side. Try for a fifth grade reading level, not a doctoral dissertation. Simple words, simple sentences, declarative voice. Picking on a semi-random example, AT&T: “to exploit technical innovations for the benefit of AT&T and its customers by implementing next-generation technologies and network advancements in AT&T’s services and operations.” That might seem a little mercenary for some folks, so it’s softened with this statement of values: “Live true. Think big. Pursue excellence. Be there. Stand for equality. Make a difference.” Note the values statement tries to follow the same rules, but has to have a 244 word explainer page with lots of pictures and shouty fonts. “Exploit technical innovations for the benefit of AT&T and its customers” doesn’t need a lot of explaining, but if you’re still not clear on your job in the biggest American telecom, it’s to “implement next-generation technologies and network advancements”.

If it is working correctly, the mission statement is used in internal disagreements and may help to settle them. Reasonable people will disagree about implementation details, but if a proposal is clearly not in line with the simply stated mission, it should be rejected. Organizational failure to do so doesn’t mean the mission statement is bad though. Google’s mission is to organize the world’s information and make it universally accessible and useful. Seems clear. So how the heck did this happen? Maybe the increased focus of an enterprise software instead of consumer and enterprise focus would help. Elastic helps people do great things with data. Splunk makes data accessible, usable, and valuable to everyone. Snowflake enables every organization to be data-driven. No chat clients yet, but maybe Zawinski’s Law is still coming for them.

If it is not working correctly, the mission statement may be ignored or mocked as a pointless artifact. This can happen when the aspiration is too vague or too disconnected from day to day reality.  If your mission statement says to do a thing that no one in the company ever works on, it might as well say that you’re all here to solve the problem of warp drive. 

Monday, July 18, 2022

Supporting a Product’s Cluster Headaches


Cluster headaches are problem reports that make everyone else in the organization ask “are we seeing that too?” and pile on. Alice suspects a memory leak and files a report. Bob tags his customers to it as well. They start discussing general performance questions in a chat or a meeting with a broad audience. Charlene through Zachariah pile on with more detail, some of which is relevant. A few days later, the root cause of Alice’s problem is found in an environmentally specific misconfiguration, but by now you’ve got an executive asking when you’re going to fix the memory leaks.

As a product manager, you may find these incidents annoying. They distract and disturb the engineers and stir up trouble with the field. However, people are people and they’re going to pattern match. Its not in your best interest to pour cold water on field people trying to help. Instead, look for ways to use these incidents to drive improvement.

  • The best disinfectant is sunlight. Open conversation about the troubleshooting process keeps everyone aware (Slack is great for this, ideally with daily summation to the ticket, but some teams use long-term meetings instead). As it becomes clear that Alice’s ticket is not what everyone else thought, their willingness to pile on decreases. There is a limit to effective openness though: people can misinterpret comments and egos can get bruised. The time lag of email based ticket comments is particularly bad for this. Someone may need to referee and keep conversation productive. 
  • Recognize that there is a problem. As a development team, perhaps you can look at this situation as a symptom of something to resolve. The X to this Y may be that there are legitimate concerns about resource utilization, and that troubleshooting those concerns is difficult. Can your team do something to improve that experience? Adding metrics and alerting on known bad states is almost always useful.
  • Where there’s smoke, there’s often fire. If cluster headaches keep popping up around the same component, that’s a signal of fear, uncertainty, and doubt. Increase enablement for that component, and listen to what the field says. If they don’t trust it they won’t sell it, so you will not be successful until they understand and trust it.

Saturday, July 9, 2022

Planning R&D Time

Granted that reality will disrupt the plan, I still find it useful to do a quarterly planning exercise. I'm fond of doing this with a zero based budget of person-time that has already had maintenance requirements removed. So you've got N full-time equivalent (FTE) people. They're going to be sick and vacating and training 25% of the quarter, and they're going to spend 40% of the remainder in meetings. If you have 10 people (keeping math simple), that’s 1920 hours of development in a quarter. Divide that in half to get the budget for feature work: 710 hours for maintenance, 710 for roadmap feature cards. Now, scope and prioritize the features you will try to deliver in this quarter. Scope doesn’t have to be perfect, an engineering manager’s estimate is plenty at this stage.

This exercise can be done in all sorts of ways, the tools and structure don’t matter. I’ve participated as everything from company leader to middle manager to product manager to subject matter expert. Maybe it’s a bunch of people in a room with post its and masking tape on a wall. Maybe it’s a series of screen share calls or physical meetings with a spreadsheet or a project tracking tool. Maybe meetings are with the whole leadership team, or subsets, or mixed. I have some dislike for a spreadsheet approach: specific project management tools or post it’s on a wall make it harder to accidentally over-allocate resources. Nothing can stop a team determined to tell themselves fibs about capacity though.

Here is the hard part: you have to leave the maintenance work untracked at the roadmap level. It’s whatever engineers feel is necessary. That budget isn’t open to negotiation or justification, it is a requirement of selling software that needs to be maintained. When a leadership team breaks this rule, then the maintenance work is no longer protected from the budgeting process. That invariably leads to it getting deferred, because hope of making money from a new feature is more pleasant than fear of losing money from decreasing quality. That deferred maintenance eventually comes back to haunt the organization, producing the highly prioritized “product get-well initiative”.

My advice to give engineers freedom to maintain is not absolute, to be clear: maintenance occurs within a budget of time. Want to refactor everything or start over in a new language? You should have to convince the entire organization to sign off on that. But you shouldn’t have to fight the budget wars in order to fix bugs.

Monday, July 4, 2022

Internal Transfers

Role, tech stack, and culture. A new hire for a role must come up to speed on all three areas, and will be coming from behind on at least one. Some organizations are lucky enough to have a broadly common set of cultural or role expectations so that people can easily transfer skills from elsewhere. Some operate in a popular tech stack that many others use as well. However, no organization is completely identical to any other, and a new hire must adjust to stated and unstated requirements.

An internal hire is already familiar with two of the three areas. Consequently they can be way faster to come up to speed. They are also a known cultural quantity, since the hiring team has had a lot more opportunities to interact than any interview cycle can provide. This means internal transfers are more likely to be a net positive than external hires when they are possible. Hiring managers will prefer them, all other things being equal.

There are arguments against “allowing” “your people” to transfer to other teams, which are largely nonsense. It's far better for the company to transfer and grow people than it is to lose them when they're ready to move beyond their role, and very few organizations have realistic growth opportunities that involve staying in one team. Put differently, if kept in one role an individual contributor (IC) can grow to be an IC over more stuff (broad instead of deep), an IC with more influence (formal guidance role), a people lead of some sort, or a combo of those things. But not everyone can meet all of their needs without a substantive role change, and there are not enough slots to allow that many role changes. Let's say you hire really well and grow 30% YOY. If half of your organization’s ICs feel ready to move up a notch in a year, at best you can serve half of them, and that's if your team gets an equal share of the growth pie. Much more likely that there's one or two growth roles per team per year and a half dozen people who should get one. If your organization doesn't have a way for them to grow inside, maybe they're going to go outside. If that IC moves to another team in your organization instead, you have much more potential to replace them on your schedule with a hire of your choice. Note the assumption of a backfill req; the ability to backfill hasn’t got anything to do with where the IC left to.

An internal hire is not guaranteed to be successful though, particularly when the role is more challenging or not well understood. Product management roles have a notably high level of bounce-off from internal hires in my experience. 

There is also the potential that an internal candidate won't pass the interviews. If it's made clear how and why they didn't pass and therefore where they might improve, they may be reenergized to serve in current role while preparing for another run at this or another new role. Without that clear feedback, the person could feel like they’re just being unfairly blocked from a hierarchy. In the absence of information many people assume the worst. They may become unmotivated or immediately move to seeking external alternatives.

Managers need to ensure the team goals are met and need to support the people who report to them in seeking their own goals. You may have wants like “minimize disruption” and “do more projects” but it's important to note those are preference rather than requirement. As a manager participating in an internal transfer, it is important to recognize the transition promptly. Set a timeline to stopping the old work and starting the new, then honor it.

Sunday, July 3, 2022

Executive Dashboards

Executive dashboards go through the Tuckman model… like team members, they have to be understood before they are accepted. 

Forming: a need for a dashboard is recognized and that dashboard is introduced to the executive staff. It may or may not be challenged, but its place is not certain.

Storming: if not at introduction then soon after, the dashboard’s ability to accurately reflect reality will be challenged. Where is this data from, how is it generated and collected, what biases does it reflect, how much delay does it contain, what role will Goodhart’s Law play if we rely on it. Perfection is usually recognized as unattainable, but most executives will want to know what risks are encoded in the tool. This process is ideally conducted offline as preparation for staff or board meetings; it’s a sign of ill health if regular meetings are derailed with storming about the tools.

Performing: Once the dashboard is understood, the executive team can work with it without a deep dive into the data that backs it, until something changes. Conditions of reality are altered, there’s additions or subtractions in the executive team, or the tools used for reporting change. Then the model starts over.

As below, so above; as above, so below. A similar process can be so served in relationships between field (sales and support) and factory (product and engineering). The list of hot issues is a dashboard.

The best choice for discoverability is spreadsheet: links to data are relatively easy to follow, and formulas and lookups are readily followed by executives with varied backgrounds. Unfortunately spreadsheets make it easy to break data links and introduce staleness. Worse, their legibility makes them corruptible; anyone working with it can accidentally change the behavior. There are mitigations and workarounds to all problems but they add brittleness. More modern data reporting systems can reduce risk of corruption by using role based access control at more granular levels. They can also help with staleness by being closer to data collection. Unfortunately, most of these systems lose the discoverability of a spreadsheet, so in my experience the most common dashboard tool for planning is still a spreadsheet.

Sunday, April 17, 2022

Gambling or Groceries?

Following on the post about sustaining software, here’s an opposing argument. 

Go big or go home. Deliver shocking value. Focus attention on exponential results instead of linear ones. Leverage your investment into the biggest possible return.

All of those exciting phrases are exciting because they mean increasing risk. Some are drawn to that risk, preferring to be a dead eagle than a live turkey. “No one ever achieved greatness by playing it safe” said Harry Gray. There’s truth to this statement: taking risk does not guarantee a reward, but a high degree of risk avoidance can guarantee the absence of reward.

And so, the question becomes how to balance pursuit of risk against safe bets, which luckily is the sort of thing that businesses have been thinking about for a long time. Unfortunately, some of the tools available to the finance department may not work as well for a product team. For instance, diverse asset allocation makes a ton of sense for a financial advisor, and is a legitimate company goal up to the point of market saturation, but becomes less great when you’re spreading your development efforts across unique and unrelated product efforts. The essence of strategy is making choices, after all, and it's potentially hard to be unified behind a single strategy as well as diversified in your investments. Still, the idea of isolating risk budget from non-risk budget has merit.

Therefore we think of gambling versus groceries, or more prosaically, Research and Development. The gambling side of the house does research into ideas that become new products, and the groceries side of the house develops and maintains the products that already exist. A very sensible model, but one that has been known to produce a house divided. If internal political pressures or external market drivers shift an R&D organization into full groceries or full gambling, then another organization will most likely be formed or funded to solve the other need.

Saturday, April 16, 2022

When to use Design Discovery Patterns


People love one size fits all patterns and models, but it is usually better to use the correct tool for the job at hand.

So you need to solve a problem. You’re going to build a solution to solve the problem with. It’s going to have users, who will configure it, give it their problems, and get solutions out of it. You’ve written some product requirements, you’ve got personas, you’ve got ideas. Then you start talking with other people and are faced with a dilemma:

* Do you Double Diamond explore the whole space of potential?

* Or do you “thin steel thread” to a Minimum Viable Product, then expand as demand drives?

The designer: “You’re suggesting an approach that covers left-to-right languages, but I see in your meeting notes that some of your customers do have operations in countries with right-to-left languages, and are you sure you won’t have need for that some day?” 

The architect: “I see you’re thinking under a dozen simultaneous admin-level users but are you sure it won’t need to be architected for thousands?” 

The engineering manager: “There’s an export data function here, what if instead of raw data dump we support PDF with an accessible color template?”

This is double-diamond thinking, and each of those ideas represents a quarter of work that you didn’t account for in your timeline.

Alternatively, the project manager comes in with “why don’t we do a non-working prototype and see what people do with it?”

And the team lead suggests: “if we constrain to a single type of conversion, we could get this done by end of the quarter.”

This is thin steel thread, developing an MVP (Minimum Viable Product), and each of those ideas is removing a big chunk of what you wanted from the first release (in the non-working case, the chunk is “everything”). Digression: a popular model for explaining MVP is the “from scooter to bike to car” blog post — which I have to say I hate, because it’s not an effective metaphor. Making and selling physical objects that don’t optimally solve a problem is tremendously wasteful, especially if you take the problems of disposal into account. Making and selling software that doesn’t optimally solve a problem is considerably less wasteful. The problem is that while software ages like milk, the cost of producing it is considerably more expensive than milking a cow.

All that said, the George Box quote that “all models are wrong, some are useful" is certainly applicable here. Both models are the right choice at different times, and the distinction is in whether your development team has the right tools in their bench for solving the problem that needs solving. 

To do the thin steel thread trick efficiently, you need to be using off the shelf components. It doesn’t matter if they are in house or OEM or open source, it only matters if your dev team is knowledgeable and comfortable with the components. If the engineers aren’t using tools that they’re comfortable with, then they aren’t able to efficiently produce successful solutions to problems. So, first job is to get the toolbox you’ll need, and that’s a double diamond job. In order to build or select and learn a good set of tools, you have to know the whole problem space that you’re going to work in.

A second factor that leads to is domain expertise, which can be a product manager’s problem. Developers spend a lot of time learning software engineering, and not the problem space that your customer is trying to buy a solution for. The purpose of these design discovery patterns is to build a minimum level of expertise in the domain, sufficient to produce useful software tools. Like any tool, they are limited to the use case that their designer intended (consciously or otherwise) and may not function properly in others scenarios. 

Saturday, February 26, 2022

Continued Improvement in Software Products

What’s more valuable to the software vendor: improving what you’ve already delivered, or building something new?

At first it might seem like building a new thing will have the highest return on investment. After all, new customer growth being equal, the finished product is only going to get support, renewal, and expansion dollars from existing customers. A new product could be sold for full price to existing customers, so more potential. This view neglects the sad fact that software ages like milk, and requires constant attention to maintain its value. An enterprise software product exists in an ecosystem of supply chains, changing standards, and data flows with adjacent products. The ecosystem changes continually, and a product that doesn’t keep up weakens and eventually dies. There are exceptions, but by and large when products stop working, customers stop paying for them.

This is why growing and sustaining software can actually have higher business value for an enterprise vendor than new projects, because it is churn prevention. The easy benchmark in sales is every dollar churned is two you have to make in new business. But in enterprise businesses that's more like 1:5 or 1:10. Why? There’s a strong chance that product failures don't just churn a product, they churn the entire relationship. Failing to maintain or add features to software that your customers are still using leads to customer churn. 

You could argue that's not true or not important if you're on a one-and-done perm license model… you’re only risking your support contract renewals, reputation, and any expansion opportunity, but you’ve sold the software and that’s all done. "Just risking reputation" or "won't get expansions" ought to give any company serious pause, but this straw man position is that it's okay to ignore software maintenance if you primarily sell perpetual licenses. However, perpetual licenses make a lumpy revenue stream. If your business is primarily living on them, then your CFO is probably pushing for a recurring subscription model such as SaaS right now, to smooth out the lumpiness. And if you’re a SaaS, you are not very likely to keep subscriptions if the software starts breaking and you’re not fulfilling your end of the contract.

New projects have potential to disrupt industry and make 10x or 100x annual ROI. Every baby also has potential to be an Olympic athlete or famous musician. The odds are against a particular new project instantly becoming a world-changing 10X, and pretty good for a much more modest rate of return that gradually improves with the application of more effort. New products that don't immediately fail are often legit businesses that could steadily grow into serious revenue generators, if they’re sustained at the appropriate tempo. Leaving them unsustained or not adding features hurts the vendor. Or they can be shut down, leaving disappointed customers and opportunities for competitors.

Squad development models can exacerbate this form of “almost made it” product failure, by encouraging shift of resources away from product that is “finished” or not driving 10x right now. Another way to produce a stagnant product is to build with assumptions that someone else will take care of content, but then never build the partnership conditions for that to happen.

Sustaining and feature growth teams are churn prevention teams, and they're very probably making more money for the company than higher profile projects. The product manager’s challenge is to make that visible and exciting. A new product with its own license has an easy path to show exponential growth; after all, it’s not hard to double and triple your yearly sales when the starting point was zero. It takes at least a year in enterprise software to recognize if that early growth will hit a plateau. Sales of big ticket software take time to complete, license bundle definitions might have changed, and feedback or demand might be muddled by context loss. Arguments for how much money an existing product makes can get bogged down in soft accounting of pull-through dollars.

Anecdata can be a powerful tool in this situation. A financial argument is always your foundation, but you can support it with positive customer quotes about what the product means to their businesses. It can be tempting to go negative and pull quotes indicating intention to churn if features aren’t built: my advice is to avoid engaging your own leadership’s fight-or-flight response. Tell a positive story of account building, value retention, and license expansions instead.

Since you’re making an argument about the future, using a probabilistic model can help reveal the opportunity (or opportunity cost). Douglas Hubbard’s How To Measure Anything has a good set of examples to follow. The inputs are current and projected business per product, probability of partial churn, probability of complete churn, and planned cost of sustaining engineering over the same time frame.

Update: more thoughts here