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.

Edit

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.