<!-- Content Here -->

Release notes: the most important documentation you will ever write

One of my favorite high school teachers used to say "if you want to learn about the world, read the newspaper." This is great advice because, by updating you on what is happening now, newspaper articles expose you to places, people, and histories that you can dig into more with additional research.

I feel the same way about release notes. Let's face it, people don't read product manuals cover to cover any more than they do encyclopedias. You read a reference resource when you want to learn more about something that you are already aware of. In the product world, you read the manual when you are struggling to figure out how to use a feature. But what if you don't know a feature exists? That is where release notes come in.

If you practice lean product development, your product should be constantly improving so there should be plenty of material to talk about in release notes. You should also have an engaged customer base that likes the product, wants to learn new ways to use it, and is excited to know what is coming next. Release notes are the ideal channel to educate these customers about product features and progress. So make your release notes good!

While they are not release notes in a classic sense (because they are not tied to individual releases) a good model to follow is the "What's new with Alexa" emails that Amazon Echo owners get. These emails are easy to read and have just enough information to tease the reader into trying something and learning more. They also mention older features that new users may not have heard about yet. In fact, I am convinced that some weeks those emails only contain older features. But they are still useful reminders!

The redesigned App Store for iOS 11 also has some of these qualities.

I pay a lot of attention to release notes for all of the products I manage. Here are some habits that I think make them successful.

• Write the first draft of the release notes at the start of a release cycle. That is, when the release is scoped and getting prepared for QA.
• Invite internal stakeholders (especially sales, support, and QA) to review and comment on early release notes drafts. You might learn about functional issues that were not considered during the initial design. You may also learn about how to better describe/position the feature.
• Make the release notes fun and easy to read. I find that humor are helpful in keeping the reader's attention.
• Make release notes required reading for staff. After sending out the release notes, I email managers a quiz question to ask their team. 
• Keep the notes short. Focus on what the change is and the problem it solves. Talking about the "why" is critical because it helps the reader understand what the feature is used for. For more details, link to longer form knowledge base articles or product documentation.
• Include a "new to you" section that describes a pre-existing feature that is under-utilized or not widely known about. 
• Copy the release notes into the Git merge commit message. This makes deployed versions stand out and searchable. 

Lean Product Development with SLCs rather than MVPs

I honestly can't think of a better way to build products and services than the lean product development method. All of the work I have done over the last several years has followed the pattern of growing a customer base around a small simple product that evolves and matures in response to the needs of the users.

Our latest product, Lionbridge onDemand, has been a great success and yet it started out so small: we were testing whether we could build a business around a self service video translation site. We built the simplest app possible but left room for growth. We leveraged operational talent that Lionbridge already had and an entrepreneurial spirit that was not being satisfied. We tested different ways to drive customers to the site. We got just enough market response to see a path and keep moving forward. Since our first sale, we have been constantly learning, optimizing, and expanding. Now onDemand is a thriving business with a broad range of services. We translate all sorts of content (over 40 file types) into pretty much any language you can think of. We have a public API and integrations with several popular content management and commerce systems. But most importantly, we have happy customers who rely on the service.

Whenever I want to build a new product, or even add a new feature to an existing product, my plan is to start with an MVP (minimum viable product) and iterate from there. But this article, "I hate MVPs. So do your customers. Make it SLC instead" by Jason Cohen, gave me pause. SLC stands for "Simple, Lovable, and Complete" and, after reading the article, I realize that SLCs are the recipe for success in lean product development; not MVPs.

Here is the difference. An MVP is (in a pure sense) the flimsiest thing you can build to answer a question about a potential market. The emphasis is more on the "M" (minimum) than the "V" (viability) and most interpret that balance as a semi functional prototype. This kind of MVP is frustrating to customers because it doesn't solve their problem in a helpful way. It focuses on validating that the problem exists and that there is value in solving it. MVPs are selfish because they prioritize research over actual customer benefit.

If you really want to learn about customer need, and build good relationships at the same time, you should take one customer problem and solve it well. Build an SLC. I know that the line is blurry here. An MVP could be an SLC if you make lovability a requirement for viability. But often you hear bad solutions as being excused or justified as "just an MVP."

The first iteration of Lionbridge onDemand did what was needed for a successful, gratifying transaction. In particular:

• The customer could upload very large files. This is necessary because video files are big.
• The project was automatically quoted so the customer didn't have to wait.
• The customer could connect with an online sales agent through chat. This turned out to be a critical feature because we learned so much from our customers during these interactions.
• The customer could pay for the service using a credit card so he/she got the experience of a seamless, self-service transaction.
• The operations team was prepared to produce a high quality deliverable in a reasonable timeframe. The customer's need was satisfied.

Three reasons why website localization projects fail

Many organizations go into website localization initiatives unaware of the complexities and best practices involved. When this happens, frustration is the usual outcome. Having seen a number of localization efforts struggle, I believe that the root causes fall into the following three categories. The good news is that all of these problems can be avoided with experience and planning.

New Blog: Lionbridge CTO Corner

I am writing about multilingual publishing on a new blog called "CTO Corner." This is a rich topic that many content management professionals never get exposed to. One of my hopes for this blog is to bring in experiences from others who are immersed in building and maintaining multilingual websites. Software vendor perspectives about managing multilingual content are welcome as well. If you would like to share, @message me on Twitter and we can set up an interview.

Just say no to standups

I never liked regularly scheduled standup meetings. They interrupt your flow. They are boring because most of what is said has nothing to do with you. When an interesting topic does come up, the standup quickly transforms into a meeting-meeting that holds uninterested parties hostage. Standups are lame.

The good news is that, thanks to tools like Slack and Hipchat, we don't need to suffer through standups anymore. For around a year, my development teams having used ChICO (Checkin/Checkout) rooms. I got the idea from this blog post by Zsolt Kocsmarszky. When team members check in, they report what they are working on, who they need to work with, and any blockers they foresee. When they check out, they report what they accomplished and their plans for the next day.

This approach has multiple advantages over the classic standup.

1. It does not need to be synchronous.
   People report in and read at a time that works for them. They are alerted when a new announcement is made and can check it in their next stopping point.
2. It is scannable.
   You can scan over information that is not relevant. 
3. It is self documenting.
   Nobody needs to capture minutes or take notes.
4. It works well for geographically dispersed teams.
   Nothing is worse than a "phone standup" and, when timezones are involved, there is no good time to have them.
5. It cuts across language barriers.
   This may be the biggest one for us. My team's written English skills are great but the spoken word is challenging due to accents and "buffering" (when the time it takes you to decipher a word and recall it's meaning makes you fall behind). Removing that barrier has brought my teams closer together on both personal and professional levels. 

In-Context Review: Know the Power of Your CMS

I am blogging again (sort of).  Here is a post I wrote on the Lionbridge Blog about reviewing content in your CMS. Crazy. I know. But you would be surprised how many people think you should be reviewing content outside of their CMS.

Internet Explorer Support

I tend to be more aggressive than most when it comes to ending support for outdated browsers. As I mentioned in this article about ending IE6 support 5 years ago, supporting old browsers is not worth additional cost and drag on innovation.

I am happy whenever I see a big web property end support for an old browser, but I was absolutely thrilled to see that starting on January 12th 2016, Microsoft will only support the most current version of Internet Explorer available for their supported operating systems. This means:

• IE8 and lower will be practically dead. It will only be supported on some embedded versions of Windows.
• IE9 will only be supported on Windows Vista (remember Vista?), which will lose support on April 11, 2017.
• IE10 will only be supported on older versions of Windows Server.

Even better, whenever Microsoft launches a new version of Internet Explorer, the older versions immediately lose support on mainstream desktops (and probably phones and tablets too).

Thanks Microsoft! It is a lot easier to stop supporting a browser if the software vendor behind it has also abandoned it.

Does the average user prefer multi-factor authentication to expiring passwords?

I was doing some anecdotal research about password security preferences and I was surprised to find that most of the people I talked to favored two-factor authentication (using Google Authenticator) over expiring passwords. My survey pool consisted of project managers who I think are pretty typical enterprise software users. Around half of them had not seen two-factor authentication until I showed it to them. The general attitude was that anything is better than expiring passwords — an opinion that I agree with.

Are my colleagues unusually geeky or is this a trend that other people are seeing as well? If you have experience, research, or intuition around this, I would love to hear from you. @reply me on Twitter: @sggottlieb if you have something to say.

Double International Snapshot

Last year I wrote a post about two deployment patterns to prevent source language bleed through when using a transaction proxy. If you don't want to click through on the link, source language bleed through can happen when a visitor views a page with text that has not been translated yet. Most translation proxies have an option to use machine translations for untranslated text but this is not always desirable.

In our experience, the "International Snapshot" pattern works very well as long as the customer is willing to freeze their content while the site is being translated. Without a content freeze it impossible to make the site completely translated. You never know when a content editor is going to publish a new string. It is also inefficient because the translators might need to translate text that is only on the site for a few hours. For example, a translator might be sent a task to translate a sentence with a typo that will be corrected in a matter of minutes.

But not everyone is willing to interrupt their publishing flow. Thanks to the wonderful world of content management systems, people are used to being able to publish whenever they want. To accommodate customers who have no tolerance for bleed through or content freezes, we have started to apply a new pattern that I call the "Double International Snapshot." This pattern is identical to the "International Snapshot" pattern but has an added layer of a translation instance which effectively freezes the content for the translators.

In this pattern, you have three instances of the site:

1. The Original Site that is serving your source language visitors today. This site can be updated regularly for the benefit of source language visitors.
2. A "Translation Snapshot" that is a point-in-time snapshot of the Original Site. This site provides a stable environment for new content discovery and staging translations.
3. An "International Snapshot" that is a point-in-time snapshot of the Translation Snapshot. This is the site that your target language visitors will hit through the proxy.

The translation process works like this. When you think it is time to refresh the translated sites, you refresh the Translation Snapshot. This freezes the content for the translators so that they can complete their work without new content constantly appearing. The Translation Snapshot can be finalized and go through all sorts of testing to make sure that it as perfect as it needs to be. Once you are satisfied that the Translation Snapshot is production-ready, you refresh the International Snapshot from the Translation Snapshot. Because the translations for the new content are already in the proxy, there will be no bleed-through.

The Double International Snapshot allows content editors to constantly publish new content to the source language site without compromising the stability of the translation environment. The translated sites can be fully verified for translation completeness and quality before going live. This pattern is an ideal solution for companies that don't want to risk source language bleed through but are not willing to compromise publishing freedom. But these benefits are not without cost, you do need to host three versions of your website and you need to build mechanisms for maintaining these snapshots. The Translation Snapshot site can be relatively low powered because it will get only a limited amount of traffic. If your site is simple and does not have any runtime server-side logic, both snapshots could be static HTML files hosted on Amazon S3. This can be done pretty easily with GNU wget.

The Three Worlds of a Product Manager

One of the most challenging aspects of being a product manager is that your mind needs to simultaneously exist in three worlds — three different realities: the present, the near future, and the distant future. Let's go through them one-by-one.

1. The Present
   This is the state of the product that everyone is using right now. To the product manager, however, the present feels like the past because it contains features and characteristics that he thought through long ago. The most relevant function of the present is as a tool to learn more about users and decide what the near future should look like.
2. The Near Future
   The near future feels like the present because it is the world that the product manager's mind spends most of its time in. The product manager is looking at mockups and prototypes and thinking about the sequence of when to deliver near future features. If you follow lean product development, release cycles are short and the actions are pragmatic and concrete. The picture of the near future is clear enough that it feels like present day. We do weekly releases so the near future can be real this week, the next, or the week after. If you use feature flags, the near future may be the current state for some users.
3. The Distant Future
   The distant future may not be that far away on the calendar (maybe a few months), but to the product manager, it is science fiction. The distant future never arrives; pieces of it merge into the near future but the rest keeps on being pushed off. Because knowledge and priorities are constantly changing, the product manager can't get too attached to the distant future. More than likely, the product manager is juggling multiple possible distant futures simultaneously in his head. The whole purpose of the distant future is to put the near future into a larger context and to force the product manager to extrapolate where decisions for the near future may ultimately lead.

Your product exists in a different state in each of these parallel universes and you need to know every detail about each of these states because people look to you as the expert. It is hard to keep these details from getting muddled together in your head and harder still to not confuse others as you talk about the product.

The hardest time to avoid confusion is when discussing a product road map. The best approach is to talk about the near future. Stick to three months or less with the details weighted towards the first month. With this horizon you are safe to talk about sequencing and dates but the most important topic is "why?" You are rapidly responding to an opportunity, testing a hypothesis, or incrementally building towards something bigger. The reason for an enhancement should fall into one of those three categories. Describe the distant future as a vision that influences your general direction. Don't commit to details or dates. You just need to paint a picture that shows that the next steps in the journey are worth the effort.

The other time when the three worlds confuse stakeholders is when they request a feature. Often what they ask for fits into a larger vision. For example, they might ask you to fix something that you plan to replace with a different approach. You need to adjust your perspective to their present (which feels like your past) and then take them through time to show your plans for the near future. You might also need to take them forward a few releases more to describe how you want that feature to evolve.

Navigating back and forth across the present, near future, and distant future feels a lot like time travel. It is disorienting when you context-shift into a particular time period and sometimes the past feels a little embarrassing when you come back from the future. Like a hero in a time travel movie, sometimes you need to repair the future by going back into the past. There is never a dull moment in product management. If you think things are boring and routine, you need to get your mind over to where the action is.