Sunday, February 16, 2020

Product Management Reading List

Inspired by Andy Nortrup’s thorough posting, I’ve dusted off my own recommended reading list. It doesn’t have reviews or feedback, just raw links. An interesting attribute of the times is that product management is recognized as an important function, but it’s not narrowly defined. That leaves a lot of latitude for recommending preparatory materials, and different lists have very different mental models of what a PM is going to do.

My approach to this has altered over the years as I’ve run more PM internships and mentored line PMs to avoid my mistakes and make their own. Specifically, I like to provide research pointers like this instead of prescriptive shortcuts; nothing kills the joy of discovery like forced march reading. While there’s a lot of interesting material here, it’s not all going to work for a given reader at the time they first see it. So poke around, find what works for you. If you’re coming from a STEM background, you may not need as much math and finance grounding as I have needed.

Product Manager Reading List

Specific to the discipline of product management

Marty Cagan, SVPG

Rob Fitzpatrick

Michael Mace

Ben Thompson, Stratechery

Eric Ries

Specific to leadership and teamwork

Kim Scott

Michael Lopp (Rands)

Passing knowledge of domains we influence and are influenced by

Thomas Freese

Seth Godin

Don Norman

Neal Stephenson

Alex Reinhart

Karen Berman

Dana Keller

Kieran Healy

Phil Simon

Sunday, January 26, 2020

Do I have a product here?

Sometimes I chat with people who are interested in starting a side business, or even leaving their $dayjob. That can be a really rewarding option if you’ve got the opportunity. Of course, there’s nothing wrong with not doing it! Some people simply don’t want to run a small business along with doing the value-adding work which brings in the money.

But if you’re willing to take on being your own boss, how should you evaluate if you’ve got a product that can float that business? Let’s work through a system for finding that answer.

Step one: Give yourself an hour per day over a week or two to do some research. You’ve got a blank sheet of paper and an idea, so let’s do some calculations and see if they can pencil out.

  • What would it cost to pursue the idea?  Do you need tools? material? People? Do you have to get certifications or build up a reputation before you can get those things? What does it cost in money and time to get to the point where you can start? What does it cost to continue operating once you start?
  • How much money must you make by what time to make it worth pursuing? Do you understand your budget? Have you considered what could be reduced and what is non-negotiable? Be honest here, if your minimum bar for quality of life requires excellent espresso every day, don’t budget for a can of Medaglia d’Oro.
  • Can you identify champions who will use your idea, gatekeepers who will allow it, buyers who will pay for it, and budget that exists today? This model is commonly used in business-to-business enterprise sales, but it’s not bad for considering any product transaction. Even if these roles are only different voices in a single consumer’s head, they will absolutely play out their functions. Consider your own purchase of a game: does your internal champion want the experience of playing it, does your internal gatekeeper approve (“what would my friends and family say”), and can you afford to buy it?

Step two: Assuming all of that pencil work comes out with a positive answer, you’re looking at refinements. Now it’s most interesting to consider: how much time will it take to prove or disprove that back-of-envelope estimate? Can you take a vacation from $dayjob and spend it on this idea? Hint: if that sounds terrible, you’re probably not going to like being your own boss. This part may be really tough because you’re going to need to validate your assumptions: talking to salespeople for quotes, talking to prospects, perhaps even asking your friends and relatives to invest. If you haven’t sold before, this is where you start learning, because if you can’t sell your idea to a friendly audience you’re certainly going to face some struggles with the outside world. In some software opportunities, it’s also necessary to ask: do you truly understand the technology that you intend to use? Do you need to spend part of this time learning to prototype your solution? Some people do very well in classes or seminars. Personally, I’d buy a stack of books and disconnect for a couple of weeks. Either is more weekends or PTO time from $dayjob.

Step three: If you’re now properly convinced you’ve got a product opportunity... how do you get from where you are now to where you want to be? How much money do you need to save? Are there trigger events or red flags you’re watching for? Now that you’re looking for the moment where you can commit to your new venture, you’re going to face additional stress from $dayjob, so keep an eye on mental and physical health.

Tuesday, January 14, 2020

Product Management Internships

An engineering internship program typically runs 6 to 12 weeks, often as a group exercise. Interns join scrums, 2-5 interns (generally 3), where there was a known deliverable on a topic of interest. They would experience the corporate version of their classes: understanding problems, sprinting to solutions, and presenting to the team on progress.

Problems to tackle will usually be areas needing investigation but not yet critical path for the business. Guidance comes from a team lead or senior individual contributor, who advises and runs a daily intern standup in addition to their team standup.

I’ve seen that program a few times. I don’t really like it... the projects can be poorly considered and don’t go anywhere, and the interns don’t end up understanding why the projects would or wouldn’t work in the real world. So it’s a lot like hackathons, only stretched over a summer instead of a week.

I’ve probably seen half a dozen force-directed graphs of data sets that could never scale at a real customer, along with a bunch of pointless dashboard re-skins. Not to mention solutions that could technically work but are not feasible in the company’s licensing model or data system.

What the interns do learn is process and culture fit. That’s not terrible, but a lot of it can frankly be taught in school instead. It’s totally wrong for product management. So how should our internships go instead?

Maybe this is regional, but in the SF Bay Area tech companies are competing for interns. You can win excellent candidates by showing why they’ll do real work which will ship. Intern wants to get a job. “Got to prove culture fit at $HouseholdBrand” is one path to that. “I shipped a feature at $Elsewhere and here it is” is another one. “Proved culture fit at $Elsewhere” is not so good.

Set that as table stakes and you’ve got a good base. Next, focus on how to teach product management. There are different philosophies for that, which I’ll touch on in another post.

Know everything, then automate!

The concept of virtual patching has set me off on a small rant.

If you’re not familiar, the concept is something like this: vulnerability scanners determine that PC42 in the CritStuff system has a nasty problem, but you can’t patch it for reasons. So instead, software magically figures out that exploiting this vulnerability requires access to port 80, and tells the nearest firewalls to drop anything headed to PC42’s port 80.

I’m down on two concepts here: the first is high risk automation. I have scars from network admission control. I’ve seen SEC filings delayed because of a properly quarantined laptop, never mind the attack ships on fire off the shoulder of Orion. Blindly implemented policy has high risk, and some knowledge of context is needed to make a proper risk-reward calculation. People aren’t perfect, but they’re better at this than software is.

The second concept I don’t trust is a requirement for pre-learning. Anything that requires the customer to learn in great detail how their systems work and what the dependencies are before they can safely act has put too much burden on the customer. Anyone remember host-based intrusion prevention systems? How about application virtualization? The environments that are simple enough to manage this way do not have sufficient resources attached to support a software vendor. Said differently, this approach has failed to find market traction enough times that it is now available as free open source.

One is supposed to argue that the virtual patching tool, like learning mode IPS before it, is able to save the customer the trouble of learning... except using those automatic tools just leads to learning about the dependency by accident instead, and therefore is still a market fail.

What about AI? What about it? A perfect robot would be more patient than a human but just as capable of learning the entire system, automating it, and maintaining the automation. But using that system would require the humans around it to either understand as well, or take a leap of faith. People will totally take that leap in order to gratify our laziness, but two or three failures will mean the system is rejected.  Can the robot be perfect? If not, can it be cheaper than a human? And is any of this conversation relevant to the far-from-perfect robots we can actually build today? Sometimes.

Sunday, November 3, 2019

Offering Multiple License Models

I’ve written quite a bit about licensing software now, you can start here to follow the whole thread. In The Platform License Problem, I mentioned some free pricing as a hide-the-sausage technique. When there are multiple markets to find product fit for, and the vendor has a software base that tackles those markets, the platform problem applies. But burying the cost of a shared platform isn’t the only reason to give away software, so let’s look at some more ways that can happen.

Freemium has grown very popular in the shadow IT, consumer tech, and open source based tech markets. With a freemium model, consumers can get your product for free without support, but have to pay for “extras”: additional features, related services, and/or support contract. The pwSafe password manager is free, but cloud-based synchronization costs. The Bear text editor is free, but advanced features cost. Splunk is free to use up to 500 megabytes a day, but costs quite a bit for more. One might say these models are equivalent to a free trial on a service, such as getting Apple Music or Spotify for a free trial. However, freemium is different in that there is no time limit; instead of getting the same features when you start paying or losing the service when you don’t pay, with freemium you can use the free version forever and get more features when you pay. It is more like the shareware model, without nag screens.

Shareware, for those who don’t remember it, was a try-before-you-buy model popular in the early Internet. The customer can download the package and use it with full functionality for a limited time, but must buy a key to continue. After timing out, the software might stop working, or continue working with nag screens or watermarks on its output. Freemium packages hosted on app stores have largely wiped this model out because they allow the small developer to outsource the tedious and complex work of handling customer payments.

Even without the app store’s help, freemium models can be great for vendors. They encourage word of mouth networking, as well as advertising from taste-makers and aggregators. Reviewers and users are happier to recommend products that new users can get for free. New users are happier to try products for free. The vendor gets low fidelity signal from the downloads and traffic of a broad pool of potential customers, and can experiment with the potential for features to convert those customers. The vendor can also instrument the free product for higher fidelity feedback. The only downside for a vendor is in mis-calibrating the free/paid version; too much value for free means failure to capture revenue. As long as costs are covered though, those are theoretical losses that can be ignored in the interest of living a peaceful life. There’s always the possibility to add a better paid feature which changes the picture.

Lite editions of premium products are a slightly different take on the same theme. Typically introduced after a successful product has gained traction, the lite edition is used to expand that product’s influence without requiring a full license for every user. AutoCAD, Visio, and Adobe Acrobat all played this game very well. This model is growing less popular as vendors embrace cloud and app-store delivery of software, but the fashions of software are fickle.

The ultimate extension of the lite version is open source: the software is free to use without time limits, and the vendor must build a business around it using services, support contracts, or enterprise features. It can be harder for an open source vendor to calibrate that free/paid value balance as well, particularly when SaaS offerings erode the value of service and support.

These models all have something in common: they allow the vendor to put basically the same software into multiple customer markets. The target market of customers willing to pay for the product is satisfied, while a broader market of potential customers is also satisfied at very low risk. The vendor can easily striate further by offering a “super pro” version for even more money, limiting complex features to the customers who need them.

It’s a great option that costs even less when starting off from a SaaS base. That said, alternate consumption models can also be overly complicated when you’re still trying to find product market fit. That struggle is particularly challenging for the open source vendors who start there on day one, with a default business model of linear-growth services that faces significant erosion risk.

Saturday, October 26, 2019

The Platform License Problem

In my other three posts about licensing, I discussed simple products. But what about platform companies?

A platform company sells two types of products: the platform, which enables everything else, and the use cases which rely on that platform to solve specific problems. The key to the platform company definition is that the solutions will not work without the platform; they are add-ons sold by the first party. You can’t buy the add-on without the platform.

This model is really exciting for vendor and customer because it means lots of different problems solved In the same way, with a single decision. There’s an interesting pricing challenge down this road though: the platform plus one add-on is less compelling than the platform plus many add-ons. Worse, the platform cost buoys the total price to a point higher than single purpose competitor products. Result? The land and expand rarely works out in first deal pricing, unless the customer cuts to the chase and buys more add-ons in the first deal.

Every platform company has this problem.  Bundles, bands, and hide-the-sausage are the only ways I know to resolve it, by encouraging multiple add-ons to be purchased in the land stage.

• Bundles: Either permanently or on promotion, sell several things together so the platform price isn’t so glaring. This doesn’t solve the single-purpose entry point problem, but it makes jumping straight to expansion more appetizing. See anything with “Suite” in the product name.
• Bands: Same thing with more complexity. See Microsoft’s Office365 price book.
• Hide-the-sausage: Spread the costs of the platform by making it “free” or “cheap” and increasing the cost of all the modules. Discourages customers from buying many solutions unless combined with bundling or banding to force a second discounting scheme in. See Google.
• Of course, hide-the-sausage can be reversed: charge once for the platform and then make all the add-ons free. Doing so reverses the incentives and encourages customers to download lots of add-ons, increasing support and development costs and decoupling financial signals from product development. This is a great way to cross the Bill Gates line: your apps are published as guidance, and your partners are encouraged to make the money that you’re not making on your platform. See Salesforce.

There is no best option, in my opinion. I will quote Clint Sharp’s comments on pricing model changes though: “a great way to initiate a denial of service attack against your PM team is to constantly start up new debates about pricing models.”

Licensing thoughts continued...

Saturday, October 5, 2019

Scripts for Adulting

  1. Hello, I’ve been admitted to the 2019 class and I have a question about my high school grades. Can you help? My reference number is #######. * Get the dates and account numbers together ahead of time.
  2. I’m going to get a bad grade in a class, or possibly a withdrawal. * Just the facts! They don’t care what happened.
  3. will this affect my acceptance to university?
  4. does it make a difference if I take the bad grade or the withdrawal?
  5. are there recommended steps I should take?
  6. what was your name? * In case you need to explain where you got advice later.
  7. thank you!

I’ve found that writing little scripts like that really helped my kids with their adulting conversations as they went through high school and into college. My daughter was very upset about the class, but it wasn’t relevant to her major so there was no point in discussing how or why the bad grade was happening.

Plan out what you’ve got to say, plot a path that your own emotional hot buttons, and gather the stuff that you can anticipate needing.

It’s a useful tool for managers as well. Tough conversations are part of the career. If you go in prepared, they are a little less tough.

  1. the company is making a change. * Just the facts.
  2. what’s the reasoning, quick outline of process. * Why is this happening.
  3. how does it impact this team. * Most positive spin possible.
  4. how does it impact you. * Simply your opinion of the reasoning and outcome, and how you came to accept that it was acceptable. If it’s not acceptable, save that for the separate communication where you announce your resignation.
  5. summarize: what’s happening, impact to this team, what should everyone do next.

If you’ve got lots of time to prepare, you might even think through some likely interactions, but that can backfire by helping you spiral back into emotional territory. The goal is to be able to communicate the facts and save your feelings for a different conversation.