Wednesday, March 2, 2016

The Myth of the MVP

Since you are here, I'm assuming you aren't thinking "Most Valuable Player." But, just in case, let me clarify: Minimum Viable Product.

It is a compelling concept for any product team: Work fast, get something out that works, see how people like it, then adapt. It is particularly appealing for new businesses or simply new products when there is no way to know for sure what prospective users will really like - or even IF they will like it.

It can even seem appealing for more mature organizations with less of an investment and time crunch because of the opportunity to accomplish something and get 'points on the board'.

It sounds great: You get to minimize risked time and capital, shorten time to market, and get users on board for word of mouth and other benefits.

So, what's are the problems? They generally come from poor application of the methodology or plain old laziness.

1) It does not meet the "Viable" part of the concept. Even getting an MVP product out the door requires some analysis on a coherent set of features that provide value to an intended user. If it is only a collection of technology proof points, users won't value it, it won't get used and the concept fails

2) It is often an excuse for not doing proper architecture work. This is actually acceptable in the MVP model. But it requires the discipline to plan to correct it later. Otherwise it ends up generating deep 'technical debt' from the beginning.

3) It is used to simply avoid doing the hard work of research, planning and decisions to place a solid bet. Frankly, this can be acceptable in the interest of speed, but the team has to be honest.


A colleague shared this link on this topic with me today. I really like the concept of "Early" product. He suggests that one should think of it as delivering the Earliest Testable Product, to be followed by the Earliest Usable Product and so on. This better maps expectations between developers and users and focuses on the idea of delivering something useful from which to get feedback

Wednesday, January 6, 2016

Top Five Posts

One of the problems of a growing library of blog posts is that some of the gems might be getting lost in the forest. So, I took a look at which posts you, my dear reader, seem to find most interesting. So, here are the top five read posts:

Sunday, September 7, 2014

Product Roadmaps - How much to share, with whom and by whom?

Roadmaps seem like such a simple concept. Simply share what you intend to build so that customers and prospects are happy. Hah! There are political, relationship, accounting and legal issues to deal with.

In the ideal world, the product manager would have a clear vision of where the product is going strategically, a good handle on available resources, and thus a solid picture of the next few release deliverables. However, this is often clouded by internal politics of decision making and who really 'owns' the product.

Not only that, Agile development processes have a tendency to produce behavior that is less predictable. It's not that Agile methods are incompatible with predictable roadmaps, (See Scaled Agile Frameworks for suggestions on how to make Agile processes more robust) just that it seems that many agile shops feel less bound by plan commitments because they write it off to dynamic change.

However, it is the duty of a good product manager to have a roadmap for his/her product. Any PM who cannot say what they hope to accomplish with their product over the next year or two and plot it on an expected timeline, is not doing their job.

The challenge is in how to communicate it and to whom.

What is a roadmap?

Roadmaps are often seen as one of a few things:
  1. A concept document to communicate the direction of the product. It should help explain what direction the it is taking and perhaps where priorities lie
  2. Some feel it should be a list of committed delivery dates for features: A release plan
  3. Somewhere in-between
As you might guess, I think it ends up being number 3. The first is really too vague to be of much use. There may be a version at that level that is used in standard presentation decks and other marketing material. But this will not contain the specifics that some are trying to get.

Similarly, it should not be a detailed, long-term release plan. Doing so is a fools errand. Unless your organization is one of the few with rigorous, long term planning and scheduling, it will never be possible to achieve the schedule. Since most software companies are trying to be flexible and agile, the whole organization will conspire toward failure with this.

Ideally, the PM is able to work with the development organization to scope out the magnitude of the requested items, plot them against expected resources and put the proverbial 'stake in the sand' about when key features can be expected. This would be at a decreasing resolution as time goes out. For the next quarter it might be relatively specific about the feature and the month. But beyond that it will be more general about the feature and specify no closer than a quarter or perhaps half year.  This then gives the company, it's customers and prospects a sense of when they can expect things without setting dangerous expectations.

Constraints to consider

  • Who is authorized to communicate the roadmap? Is it only the product manager? Or perhaps a trusted and trained set of marketing and sales people who can properly frame the discussion?
  • Who is allowed to see the roadmap? Are prospects allowed at all? Under what conditions?
  • How do you control the document?
  • Do you record who has seen the roadmap?

What are the pitfalls of sharing?

First and foremost: If you don't have realistic expectations of achieving the roadmap, it will always be a problem. See this article for more discussion
  • Angry customers: Once any communication has been shared, there is the risk of disappointment. There are ways to mitigate this through careful communication and updates, but no way to prevent it.
  • Inability to recognize revenue: In many situations, revenue recognition must be deferred on new sales if a meaningful future feature has been disclosed to a customer. The theory is that if they purchased based on the future promise, the revenue cannot be recognized until and unless that feature is delivered. Unmanaged, this can be disastrous to the business.
  • Non renewal: In the SaaS world, constant improvement is expected. When roadmaps are shared and they don't meet expectations - on features or time - customers may look elsewhere and they might not even tell you.

Saturday, August 2, 2014

How do you really spot a good manager?

I recently read a great article on what makes for a good manager. I found myself in complete agreement and probably can't do better myself, so I'll let you read it directly:

The biggest thing I can emphasize are three of his points regarding how to make sure you are working for a good manager:
  1. Pronoun choice. First person singular is a warning sign. Plural is encouragement. This one isn't an absolute but I've found it to be an incredibly high correlation.
  2. Ask about management style in the interview. I've found every boss I've done that with - and had a good conversation about it - turned out to be a good boss and it facilitated our eventual working relationship
  3. The openness to hire people with greater potential and/or skills than themselves and not worry about it. This one is one of the best signs available. I once had a hiring manager explicitly say that he was "hiring his replacement". He had no immediate plans. But he knew that a) someone capable of doing his job (soon) would do the job at hand well with minimal supervision b) having a replacement made it easier for him to get promoted himself. Both were true.

Wednesday, May 1, 2013

Do you need to be an engineer to be a technology PM?

Of course not! But you do have to grok technological issues.

Many non PM hiring managers get wrapped up in this one. Particularly challenged is the engineer wo has evolved to a management role and who is tasked with hiring his/her first product manager. But it applies to many others as well.

To some extent, it is a false question. It presupposes what the PM should be doing. Good Product Management is about determining the "what" should be done:

  • Listening: To customers, the market, the business, sales, analysts, anyone relevant
  • Understanding the possible: What will your technology allow. What's easy, hard, cheap, expensive. What will people pay for and how.
  • Synthesis: Taking uncoordinated input and bringing it together into a strategy that can be built and sold
PM should not focus on the "how" it should be done. Do not try to:
  • Drive technology choice: Unless it is part of what the customer needs, which technology to use is not the PM's job. 
  • Data models, tool frameworks and other implementation decisions, unless it directly impacts the customer-facing results
There ARE exceptions. Sometimes the product itself is sufficiently technical that aspects of 'how' it is implemented are part of the definition of 'what'. The best example of this I've dealt with is when the product is an API. In such a case it may be completely relevant to the PM's role to define specific parameters of input and expected output because these things define what will be delivered to the consumers who happen to be engineers. I coined a term for this in the What vs How world: It is a "Specific What"

Funny story: I even remember a time when ALL Intel job postings had "EE/MSCS" in the requirements. This was true for even pure, outbound (i.e. 'Intel Inside') marketing positions. After I snuck in, I told people that I was a 'single E' (Econ major). Whether they were amused or confused told me a lot about them.