<!-- Content Here -->

Where content meets technology

Oct 10, 2017

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. 

Oct 03, 2017

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.
While we launched the first iteration of Lionbridge onDemand quickly (less than 2 months from concept to first sale) we took the time to get those pieces right. That was a little over 4 years ago and our first customer continues to do business with us.

We are constantly adding new features to Lionbridge onDemand and every time we do, we treat it as an MVP SLC. We don't launch the feature unless it makes the user's experience a little better by solving a problem (however small) in a complete and satisfactory way.

Sep 11, 2017

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.


1. The website was not designed for localization

Some websites are easier to localize than others. In the worst case, it is better to start over with a new website rather than try to remediate and localize an existing site. The best time to prepare a site for localization is before it is built. You need to select a suitable CMS and follow best practices during implementation and content development. If you didn't build the website with localization in mind, you (or your integrator) probably didn't follow these guidelines, which are usually the first corners to be cut when budgets and timelines get thin. The worst part is that you won't know how prepared you are for localization until you try it.

Don't let the integrator leave until you have successfully, published your second language. If your integrator is already gone, a quick assessment can reveal warning signs so you can get a head start on remediation.

2. No global business strategy

Multi-lingual publishing is (or should be) part of a larger strategy to extend your market into other languages and cultures. If you succeed in getting noticed by different language speakers but fail to help them get value from your products and services, you are no better off. You need to make sure your products, sales, and customer service are sufficiently prepared to serve these new customers. Otherwise your localized website becomes an expensive burden that is tempting to neglect rather than  an investment that drives growth.

3. Lack of commitment

A common failing is to treat a website as a technology asset that can be neglected after launch. Your website is not a project. If you want your site to engage with your audience, you need to stay engaged. Multilingual publishing raises the stakes by adding another dimension and cost multiplier to effective website management. If you can't justify the cost of maintaining localized sites, they will rapidly degrade into an embarrassment. The web is littered with rotting websites. The worst examples are localized websites that have fallen into disrepair after initial translation.





Aug 26, 2016

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.

Aug 17, 2016

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. 
Given these advantages, I am surprised when I hear about teams that still do standups. Please join me in saying no to these silly little meetings.

Jul 14, 2016

Apr 10, 2015

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.

Apr 01, 2015

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.

Mar 23, 2015

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.

Double International Snapshot

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.

Mar 16, 2015

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.

← Previous Next → Page 2 of 73