Tuesday, March 14, 2017

What's in a code name?

Many tech companies create code names for their various products or release projects. They can be totally random (SwampMonkey, Weeping Angel (thanks CIA)), or variations on a theme (rivers, mountains, obscure islands). Their purpose is to give a name to something that shall not be named. Sometimes because the official branding isn't determined. Sometimes merely to keep the branding secret. Either way, the names often create some camaraderie and team focus while working on the project.

Some companies impose restrictions on these code names as well. Usually because they have faced issues with code names before or simply have heard of too many issues.  Here is a funny example of legal backlash in real life.

Back in the early 90s, Apple was working on a new mid-tier Mac. It was to be powerful but affordable one by standards of the day at ~$3000 with a whopping 250-700MB (yes, you newbies, megabytes not gigabytes)  They thought it would be fun to honor famed astronomer and science educator Carl Sagan by naming the project after him.

Well, Mr Sagan wasn't really happy with Apple corporate at the time and complained publicly to stop it:

For this reason, I was profoundly distressed to see your lead front-page story ‘Trio of Power PC Macs spring toward March release date’ proclaiming Apple’s announcement of a new Mac bearing my name. That this was done without my authorization or knowledge is especially disturbing. Through my attorneys, I have repeatedly requested Apple to make a public clarification that I knew nothing of its intention to capitalize on my reputation in introducing this product, that I derived no benefit, financial or otherwise, from its doing so. Apple has refused. I would appreciate it if you so apprise your readership.”    - Letter to MacWEEK 

Well, this public complaint forced a name change to BHA.  What's that? I'm sure officially, nothing. But it also came out that it really stood for "Butt-Head Astronomer".  Yeah, that didn't make Mr Sagan happy either and brought on a lawsuit.

The judge responded to the claim
“There can be no question that the use of the figurative term ‘butt-head’ negates the impression that Defendant was seriously implying an assertion of fact. It strains reason to conclude the Defendant was attempting to criticize Plaintiff’s reputation of competency as an astronomer. One does not seriously attack the expertise of a scientist using the undefined phrase ‘butt-head.'”
  • Butt-Head is a word that implicitly makes everything else silly
  • Therefore the rest cannot be taken as serious defamation
The point of the story is to consider your code names with some thought to who might take offense or feel their brand might be coopted but don't take it TOO seriously. That's what brand searches are for.

BTW, after the lawsuit, they changed the name again to LAW.  "Lawyers Are Wimps"

Source: Today in Apple history: Power Mac 7100 lands Apple in hot water with Carl Sagan

Wednesday, February 1, 2017

Top 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:

Friday, September 23, 2016

No, I do not want you to restart my machine NOW

As our lives become more and more intertwined with bits of technology, the way that such technological tidbits are managed and upgraded starts to matter more and more. It becomes a part of the user experience just as much as the day to day UI.

In my professional role with my SaaS products, we no longer tolerate messages like this:

Instead, we design and deploy systems that can be managed and updated while still operating. It is actually pretty cool how it is possible to "change the engines while in flight".

But these tricks work when deployed to fleets of systems in the cloud. Not for individual systems. However, we must stop tolerating bad behavior at the individual system level too. I can be better.

Just this week, I got to experience the 'right' and 'wrong' way of updating a personal system. First the wrong way.

This is how Microsoft is doing it on Windows 10. This IS the improved version when you compare to Win7 or older.  It did try to notify me beforehand. And it is trying to make it easy to stay current. However, they still don't 'get it' on how to make the process work for regular people.

  1. There is no opportunity to schedule the restart. There never was. The earlier messages before the reported unsuccessful attempts simply said it would happen outside of normal hours. Guess what, outside of normal working hours, my laptop is not plugged in so it won't do the reboot - ever.
  2. 5:32pm is NOT an 'off hour' to do this. I could very easily be in the middle of something then. Now, I suspect that at 5:32 it will offer to let me cancel the restart - IF I'm looking at the screen at that moment. But that's not good enough. How about asking me when would be good (see #1 , above)
  3. I can reboot NOW. But I should save my work first. Uh... Wait a minute, what were you going to do in the middle of the night or at 5:32pm today? And this is a modal pop up. So I can't push 'restart now' AND go save my work in any open programs. Duh!
Let's compare to an alert I saw earlier this week. This one on a car (well, some joke that it is a computer on four wheels). Look what they got right:

  1. This dialog comes up after the user clicks on an indicator that there is something to read. It does not pop up modally and interrupt the use of the device. I suspect that at some point it will be more invasive if ignored, but still passive at first
  2. The first option is to schedule the installation and restart. The default behavior recognizes that this device belongs to the user and respects the user's choices. Yes, the fact that it is a car with life-safety implications probably pushes the engineering team that way but that doesn't excuse the lack on other devices.
  3. It provides a simple, straightforward way to pick a non-default time to do the update
  4. It provides an option to just do it now and get it over with
  5. What is a little bit of a miss is that there is no explicit way to say 'go away I can't deal with this now'  But it is there implicitly in that closing the dialog has that effect.
How about we cross pollinate our tech worlds and apply this thinking to PC software as well

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

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.