Enter Content Here

Hot Lots

2019-12-09T16:10:00.000-05:00

When I start working with an established software development team, my favorite tool for understanding their process is a "hot lot." Hot lot is a manufacturing term where an order is expedited by being allowed to jump the queue. Hot lots are closely watched for progress and potential delays. In the world of software development, a hot lot can be a feature request that goes through a process of design, implementation, testing, enablement (documentation), release, promotion, and evaluation. A hot lot should accelerate the process by adjusting priorities but it should not circumvent the process by breaking rules or cutting corners.

By prioritizing a feature and watching it go through the process at top speed, you can learn many things. For example, you can learn...

Whether the process is even responsive enough to accept a hot lot. Sometimes engineering is tied to rigid roadmaps and nothing, no matter how important, can jump the line. This is concerning if those roadmaps stretch out beyond the opportunities you can reliably anticipate.
Whether there even is a defined process. Is there a mechanism for ensuring all of the tasks (qa, documentation, deployment, etc.) are completed? Or maybe there is a process but nobody follows it. If there is no practiced process, you can't trust the integrity of the system or whether anything is really "done."
How the process is structured into steps, roles, and hand-offs. How many people touch the feature? How much time does each step take? How much time is spent waiting between steps? Is there excessive back and forth? Lean Six Sigma has a great framework for studying process cycle time, wait times, and waste across the value stream.
The theoretical speed limit of the current process. You will never know how responsive your process can be when you always slow it down with competing priorities. Often actual speed is much slower than potential speed because of various delays, distractions, and interruptions that are not the fault of the process.
Whether there are structural blockers like "we only release every 3 months." Or maybe the team is distributed over many time zones with little overlap for hand-offs and feedback.
Whether there are capacity blocks like "Joe is the only person who can do that step and he is not available."
How easy it is to monitor the process. Can you go to one place and see the completed and remaining work?
The amount of managerial overhead that the process requires. For example, is there a project manager that needs to track and delegate every task?
The artifacts the process creates. Can you go back and see what was done and why?
How the response to the feature was measured and incorporated into future improvement ideas.

After running through a couple of these experiments, I have a pretty good understanding of the process structure, its theoretical speed, its strengths, and its flaws. At that point, we can start to come up with ideas for improvement. The low hanging fruit is usually pretty obvious ... especially to people who have been participating in the process but not paying attention to the overall throughput. Optimizations can be designed collaboratively and tested by future hot lots. I find that teams are generally comfortable with this evaluation because it doesn't target people as much as the framework that people work in. Usually processes (at least as they are practiced) form organically so nobody feels threatened by process improvements -- especially if they are clearly supported by empirical evidence.

Even if you have been working with a team for a while, try pushing through a hot lot and pay close attention to it. There is really no better way to understand the execution of a process.

What problem are we solving?

2019-11-07T08:58:00.001-05:00

Before building any functionality, a product team should first start by fully understanding the problem they are being asked to solve. This may sound obvious but I can’t tell you how many times I see one-liner Jira tickets that ask for something without explaining why. But the “why” is the most important part for a number of reasons.

The team has to agree that the problem exists and is worth solving. The impact and urgency is a primary factor in prioritization.
Being grounded in the “why” informs creativity to answer the “what” and the “how.” Design begins with empathy and you can’t have empathy if you don’t know what your users are struggling with.
Solutions should be evaluated on how well they address the problem. This evaluation should drive design, QA, and post-release review.

To help people focus on the problem, I use a simple tool that I call a “problem definition.” This is a document (preferably a wiki page) that describes the problem and why it is important: inefficiency, risk, etc. There is also a section for proposed solutions where the author can suggest their ideas. The problem definition then becomes a focal point for clarification and learning. Stakeholders can ask questions to explore the use case.

I think this type of document was the original intent behind the “User Story” used in various agile methodologies. But over time, the User Story has been corrupted into a formulaic and useless “As a _____, I want to ________ so I can ________”; I have yet to read a User Story that really got to the heart of the problem and why it was worth solving.

Problem definitions are precursors to project artifacts like specifications and work items. They should be easy for anyone to write in their own language. No commitment is made to implement a solution. Sometimes problems can be solved with training or better documentation. Even if no action is taken, expressing and hearing these issues is important in bridging the gap between the product team and its users.

Everyone on the team should be able to answer the question “why are we doing this?” If they can’t, they can’t be expected to be contribute to an effective solution.

Users want easy. Developers want simple.

2019-10-23T12:03:00.001-04:00

One of my favorite tech presentations is Rich Hickey’s Simple Made Easy. The premise of the talk is that simple and easy are not the same thing. In fact, you often sacrifice simplicity in pursuit of easiness. As Rich says, we consider something easy if it is “at hand.” Like the Staples Easy Button. Simplicity is something totally different. It is the absence of complexity - lots of moving parts entwined together in intricate ways. If an “easy button” really existed, it would be supported by a complex network of solutions that could take care of any problem.

Rich was talking about programming and how to keep code maintainable. Simple code is easier to understand and extend. But I apply this perspective to lots of things. For example, a bicycle is a simple machine. A quick glance reveals how it works and what every part does. But pedaling up a hill is not easy. A modern car is complex. There is a lot of stuff going on under the hood and nearly all drivers accept that they have no hope of understanding it all.

In building software, I have come to realize that users only value ease. A user wants the features he/she likes “at hand.” In a mature, multi-featured application, UI design is mainly focused on hiding some features to make the frequently used ones stand out. Users don’t want simple. Take away any feature and there will be complaints.

Developers want simple. They want to work with code that is understandable and behaves predictably. They realize that every new feature is supported by hundreds of lines of code that need to be tested with every modification. Much of Rich's talk deals with programming styles that unnecessarily create complexity. But some requirements will force even well designed code to become complex. Ironically, these requirements are often driven by a desire for a "simple and easy" user experience (personalization, natural language inputs, voice control...).

Why does this matter?

If we don't acknowledge that "simple and easy" are in conflict, there will be unmet expectations that lead to friction between stakeholders. Users can become impatient discussing complex details about their "simple feature." Development teams can feel under-appreciated for the effort required to do a "simple thing." The time taken to wrestle with ignored complexity can look like incompetence.

Take, for example, the Google search box. It is easy to use... just type in some text and click the button. But it is anything but simple. There is an art to constructing effective queries and a whole industry (SEO) dedicated to manipulating what comes back. There is also a set of features that makes the search box like the command line for the web. I can't tell you how many times I have heard "I just want something simple like Google." Google isn't simple. But it is easy. What makes Google search feel easy is that the core functionality is obvious and it gives useful feedback to help you get what you want. You may not get what you want on the first try, but it is easy to refine your search to hone in on your target. Voice assistants aim for the same level of ease but I find the trial/error loop to be more frustrating. That is probably because the system can return only one response and the feedback loop takes longer.

I know how annoying it can be for someone to pick at language and I am not advocating to constantly correct people on their word choices. But I do think it is important for everyone to understand what they are asking for and what they are giving up when they get it. We can do that by probing into what the user means by "simple." That question is reasonable because both "simple" and "easy" are subjective terms that require elaboration. When we document requirements, we should avoid all subjective language. After all, most of the work to achieve the perception of ease and simplicity is through iteration and refinement. These qualities are not intrinsic to the feature but rather to the sentiment of the user.

Email is the portal

2019-05-23T14:44:00.002-04:00

Aberdeen is a Market Intelligence company. We provide market data (Firmographic, Technographic, Leads, and Intent) as well as quantitative and qualitative insights based on those data. My primary role as Chief Technology Officer is to develop and improve products that deliver and maximize the value of these data and insights. This is really the same "right content, right context, right time" problem that I have been working on for years as a content management professional.

Our strategy for detail data is to push them directly to the systems where they are actionable. For example, our Aberdeen Intent for Salesforce app creates Salesforce opportunities out of companies that are showing intent. The Salesforce app also includes some charts to visualize summaries and trends. We also have other apps to help Salesforce users interact with our firmographic and technographic data. But Salesforce accounts are often rationed and not everyone spends their time there. The conventional answer to reach other users is a customer portal.

But does the world really need yet another portal?

Technical and non-technical roles are forced to work in so many different platforms. I feel especially bad for marketers (queue the scary Brinker SuperGraphic). But every office job today seems to involve logging into different systems to check in on various dashboards or consoles.

Yes, single sign-on can make authentication easier. But SSO is rarely configured because so few of these systems are owned by Corp IT. Plus, you need to remember where to go.

Yes, an email alert can suggest when it may be worthwhile to check in on a dashboard. But establishing the right threshold for notification involves time consuming trial and error that few have the patience for. It only takes a few "false alarm" notifications to make you hesitate before following a link.

Corporate portal technologies tried to solve this problem by assembling views (portlets) into one interface but the result was both unwieldy and incomplete. There is a constant flow of BI initiatives that try to solve this problem by bringing the data together into a unified place. Too complicated. Too cumbersome. And yet another place to go.

So most users are doomed to flit from portal to portal like a bee looking for nectar.

I am starting to believe that we already have the unified, integrated portal we have been looking for. It is the email client where we spend hours of every work day. Rather than develop a dashboard or portal that people need to go to, deliver simple glance-able email reports that highlight what is new/different and needs attention.

Longtime readers of this blog may be aware of my contempt for email as a collaboration and information management tool. However, even in the age of Slack, there is no more reliable way to notify business users than email. Decision makers live in their email clients. If you want to get information in front of someone, the best place to put it is in their inbox.

Designing email-friendly business intelligence is not trivial. Beyond the technical limitations of email clients' HTML rendering capabilities, you also have to consider the context. People are already overloaded with email so the reports need to minimize cognitive load. They need to quickly convey what is important within a couple distracted seconds. Perhaps even on a mobile phone in between meetings. Less is more - just a few Key Performance Indicators (KPIs) to make the user feel like he is in the loop and can answer questions about the status of the program or take action if necessary.

Frequency is also an important factor. The cadence should align with the decision making cycle. These emails are not for catching daily anomalies. Those types of warnings are better handled by system alerts that only go out when thresholds are met (behind schedule, over budget, no data detected...).

As I think about a portal to deliver Aberdeen's market intelligence insight, I keep going back to the question, what if our BI portal wasn't a portal at all? Wouldn't it be better to put our data into user interfaces that our clients are already looking at?

Who is replacing WordPress?

2018-07-12T09:57:00.000-04:00

I have been working on an interesting data set about web content management system (WCMS) installs. From these data I am able to identify events when an organization rebuilds their website on a new WCMS. As anyone who has been involved with a web development project knows, a website re-platforming represents a lot of time, expense, and decision making. So these events are important market signals -- especially when you consider the platform they are leaving and how long ago it was deployed.

I am starting to publish interesting observations on the Aberdeen Blog. This first post lists which WCMSs most commonly replace WordPress. I am doing similar analysis on other software categories such as eCommerce.

Subscribe to the Tech Pro Essentials channel of the Aberdeen blog if you want to see more posts like these.

My Growing Data Science Toolkit

2018-06-20T10:24:00.000-04:00

At Aberdeen, I am taking vast amounts of data and working them into a unified data model that encompasses company information, web traffic, survey results, etc.. The actual workflow is nicely summarized in this classic dataists post called “A Taxonomy of Data Science”: OSEMN (Obtain, Scrub, Explore, Model, iNterpret).

Here are the tools and tricks that I use on a daily basis.

Command Line Tools

Massive data files are troublesome for most editing programs (such as Excel or even VIM). It takes too much memory to hold all of that data in an editable state. Command line tools don’t have this problem because they work with data as a stream so they only need to load one line at a time.

Kade Killary wrote an excellent article called “Command Line Tricks for Data Scientists” . The tips range from simple to advanced. On the simple end, I learned about “wc -l” which is the fastest way to get the number of lines in a file. Split is also a simple but powerful command for doing things like breaking up a large file into smaller batches for things like Mechanical Turk (more on that later).

When working with CSV files (the lingua franca of data science), I couldn’t live without CSVKit. It doesn’t do anything you can’t do with AWK but the syntax is optimized for working with CSV files and is much simpler. For example, “csvcut -n filename.csv” lists the names of each column in filename.csv. “csvcut -c 1,3,4 filename.csv > newfile.csv” exports columns 1,3, and 4 into a new CSV file called newfile.csv. csvformat is useful for handling delimiters and escapes so that the file can be ingested by other systems.

As an aside, I always work with plain text formats such as CSV because they are more accessible to different tools than binary formats such as Excel.

Mechanical Turk

Most data scientists throw away data that they can identify as bad. Unfortunately, I don’t have that luxury. For example, if I discover that the URL we have a company is incorrect, I need to fix it because I use domain to link to other data. But what do you do if you have over 100,000 missing or bad URLs? Automation can only take you so far. After a certain point, you need an actual human to do some research. I have found that Mechanical Turk is the fastest way to get help with these manual tasks. Using Mechanical Turk effectively is an art that I am just starting to get proficient with.

Git

When working with data files, there is a tendency to save copies in various steps in the process so you can compare what has changed, recover from a mistake, or take a different approach. Before long, you get directories full of cryptically named files. Some people have developed good systems for organizing and naming these files but I think the best approach is to use a source control system like GIT. With GIT, you can commit a version of the same file with a comment about what you did with it. And, of course, Git helps you work with others.

VisualDiffer

While GIT comes with comparison functionality to show the difference between versions, I don’t think it is particularly easy to use. VisualDiffer is a cheap and simple tool to show side-by-side comparisons of text files like CSV. More advanced (and expensive) tools like Beyond Compare, Araxis, and DeltaWalker can handle binary formats such as Excel and even merge differences. But I have not found a need for those yet. My most common use case is to see changes that a script or someone else made to a file.

AWS

I use a lot of AWS tools in my work. S3, DynamoDB, Lambda…. At the bare minimum EC2 is a quick and cheap way to set up a computer that I can execute a long running process on. For example, I have one automated process that goes through hundreds of thousands of records and uses various APIs to gather additional data. The process literally took weeks. Using EC2 and screen sessions is infinitely better than chaining my own workstation to an internet connection and having it run continuously for days.

Pandas and Jupyter Notebooks

Since I am already a Python programmer, Pandas and Jupyter Notebooks were an obvious choice for exploring and modeling data. I love how you can build a step by step annotated process to assemble and visualize the data.

PowerBI

At Aberdeen, we add another step onto the end of the OSEMN process: Publish. This is where we use the output of our research to deliver interactive data products to our customers. Those products include embeddable dashboards and alerts that customers can use to make better decisions and seize opportunities. PowerBI is a rapidly improving platform for delivering interactive reports. We have PowerBI experts on staff so I mainly send data for them to turn into customer facing tools.

New Job: VP of Research Products at Aberdeen

2018-06-15T16:13:00.001-04:00

I am excited to announce that I am now working at Aberdeen where I am the Vice President of Research Products. This is a big time at Aberdeen because we are shifting from a traditional analyst firm to what we are calling a "Market Intelligence" company. What that means is that our analysis is based on quantitative data rather than anecdote and opinion.

In particular, we are focusing on three categories of performance indicators:

Awareness quantified through surveys that ask respondents whether they are familiar with a product or brand.
Consideration, which is based on intent data.
Market Share, which is based on install data.

You can read more about the methodology on our solutions page.

In this role I have gone deep into data science and also tapped into my own nerdy creativity and curiosity. If you like FiveThirtyEight and Freakononics, you would love my job. It's especially great for me because it allows me to leverage many skills I have developed over the years as an industry analyst, software developer, and database administrator.

Lately I have been exploring historical install data to analyze events where one web content management system replaces another. For example, when a company replaces a website running on WordPress with a new website running on Sitecore. Re-platforming events such as these are significant because they represent customer requirements, product strengths (at least strengths perceived during the selection process), and big investments of time and money. And then when you combine that with intent data that shows which customers are showing signs of looking for a replacement technology, you get highly actionable insight.

These data will be incorporated as features in our subscription products but I do plan to post tidbits on the Aberdeen blog. So stay tuned!

Silos everywhere

2017-11-17T12:10:00.001-05:00

It is fairly typical for a consultant or new leader to walk into an organization and see nothing but silos. These leaders regard silos as a barrier to efficiency and make them a target for change. What they often wind up doing is replacing organically formed structures with new ones that look better on powerpoint than in practice.

Why does this happen? Let's start by digging into what a silo is. "Silo" is usually used as a derogatory term to describe a grouping that you don't like. But groupings are important in large organizations because the number of possible point to point connections makes communication too noisy and prioritization too difficult. If everyone is talking to everyone all the time, nothing gets done. Teams naturally form to confront this challenge. Complementary capabilities are assembled and scaled in highly focused work groups. Process is continuously refined because of a tight feedback loop.

To the outsider, trying to navigate these structures is confusing and frustrating. People seem unaware of what is happening outside of their group. They appear oblivious rather than focused. The reactionary impulse is to criticize the duplication of what appear to be identical functions. The ego feels good when you think you see obvious dysfunction that nobody else recognizes. It certainly feels better than having to slog through complexity that everyone else understands.

But there is great risk in introducing sweeping plans to achieve synergy before really understanding how these teams function. Even if the reasoning is valid, it is incredibly disruptive to blow up any working system and make it re-form under stress and uncertainty.

Before eliminating "silos," you need to understand why they formed. Were they imposed from the top down in order to make the organization easier to understand from the top? Or did these structures develop naturally to solve operational problems related to coordination and focus? Can the same benefits be achieved more efficiently?

You can't fix a working system until you fully understand why it is the way it is. You need to understand what is working right now and what obstacles stood in the way from the system naturally adapting to solve its broken parts. When you hypothesize dysfunction, you need to introduce your corrections scientifically and measure the results. But most importantly, you need to find the best parts and figure out a way to expand on them.

When remote working doesn't work

2017-10-23T16:00:00.001-04:00

As a long time remote worker and manager of both distributed and co-located teams, I think about virtual teams a lot. While I have had great personal experiences with remote teams, there seems to be little consensus about whether it is a good idea. You have some articles touting the health, retention, and productivity benefits of letting people work from home. And you have other articles, like the recent Atlantic piece "When working from home doesn't work," that indicate a shift back to traditional office environments. Based on my own experience, I find it hard to imagine large companies succeeding by dictating enterprise-wide policies around remote workers. The effectiveness of distributed teams depend on critical factors that will vary from team to team. Here are three things that undermine the effectiveness of distributed teams.

1. Hybrid teams do not work

A team should be either all colocated or all remote. A remote member of a predominantly colocated team will always be neglected. It is unavoidable. Co-located employees build habits that depend on seeing each other. They look around the room to decide who to include in a discussion. They respond to visual clues that a colleague may be struggling. The interactions that are available to remote team members tend to be restricted to events that are either boring (like standing meetings) or stressful (like performance reviews). But relationships are formed in between these two extremes when people can be themselves and have the space to curious about each other and build trust.

2. You can't convert a colocated team to a distributed one

A team is not just a collection of people. It is an ecosystem that is shaped by individual talent, chemistry, goals, and an environment that presents constraints and opportunities. The environment plays a huge role in how people interact. And by interact, I don't just mean communication (although that is part of it) but also how responsibilities are divided and handoffs happen. If all of the sudden people start working remotely, you need to treat the group as a new team. You need to establish new norms and ways of working together. Roles will change. You need to use different methods to develop camaraderie and create an engaging work experience.

3. Not everyone will thrive as a remote worker

It takes a special type of person to be an effective and happy remote worker. Their work environment has to be conducive to productivity. They need to be goal oriented and invested in the success of the team. They should be committed to their craft and want to build mastery by continuous refinement. I have also recently begun to appreciate the importance of being in the right phase of one's career. At some point in your career, it is helpful to go into an office to do things like: build professional social skills; find a mentor; bond with people; try different roles; get lots of feedback; and have the general sensation that you work for a company. It is harder for remote workers to advance into new roles because they don't get to see other people doing those roles. Personally, I am grateful that I got to work at a number of different kinds of offices and I have some great professional connections from that time. I think I would be a wreck if my early managers had to deliver feedback over phone and email without being able to modulate tone and provide support based on my reaction.

Based on these three observations, a smart executive will not dictate working style based on business journal articles or office leases. Instead, he/she should empower teams to construct and distribute/consolidate themselves for optimal efficiency.

Release notes: the most important documentation you will ever write

2017-10-10T08:30:00.002-04:00

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

2017-10-03T11:00:00.000-04:00

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.

Three reasons why website localization projects fail

2017-09-11T10:00:00.000-04:00

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.

New Blog: Lionbridge CTO Corner

2016-08-26T08:38:00.000-04:00

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

2016-08-17T08:47:00.002-04:00

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.

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.
It is scannable.
You can scan over information that is not relevant.
It is self documenting.
Nobody needs to capture minutes or take notes.
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.
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.

In-Context Review: Know the Power of Your CMS

2016-07-14T13:38:00.000-04:00

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

2015-04-10T09:53:00.001-04:00

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?

2015-04-01T13:38:00.001-04:00

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

2015-03-23T11:32:00.001-04:00

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:

The Original Site that is serving your source language visitors today. This site can be updated regularly for the benefit of source language visitors.
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.
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

2015-03-16T09:25:00.001-04:00

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.

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.
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.
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.

Drupal is to web development as Powerpoint is to design

2015-02-24T14:57:00.001-05:00

I was recently talking with a friend about how hard it is to find a good Drupal developer. While Drupal is the second-most widely used CMS, finding developers who know how to work with it properly is really challenging. I think there are three reasons for this.

Drupal is so ubiquitous that most PHP developers have had at least some level of exposure to it.
You can get a lot done in Drupal without knowing what you are doing.
Most of the people hiring Drupal developers are not able to evaluate the quality of the work.

In thinking about this, an analogy came to mind:

Drupal is to web development as Powerpoint is to design.

PowerPoint is everywhere. Anyone who knows a little bit of PowerPoint, and can search the web for images, can convince himself that he is an adequate designer (or at least a good visual communicator). But the more you care about design, the more horrifying these amateur presentations are. PowerPoint itself isn't bad. If you do have good design skills, PowerPoint can be an incredibly powerful design tool. But there are more bad designers working in PowerPoint than good designers.

Similarly, Drupal has a huge library of modules that you can install and configure about as quickly as you can drop an image onto a slide. An expert Drupal developer will know what modules to use, have good judgement of when to use them, and have a solid process for testing and managing configurations. A Drupal amateur is unaware when he is creating a mess that is going to create embarrassing situations in the future.

So how do you separate the wheat from the chaff in the Drupal developer ecosystem? I tend to focus on three areas:

The types of sites the developer worked on. Wrong answer: "I build Drupal sites all the time."
How the developer finds modules to use. Wrong answer: "I just search for them."
How the developer manages configurations across environments. Wrong answer: "I just click boxes."

By asking these three questions, I can usually get an idea of expertise and craft that a Drupal developer applies to his work. Happy hunting!

Rediscovering Private Chat

2015-01-08T08:31:00.000-05:00

A few weeks ago, I moved my development team from Skype to HipChat for chat-based collaboration. All the buzz around this new breed of collaboration services (such as HipChat, Slack, and Flowdock) was making me curious. I had used private chat room technology like IRC and Jabber in the past with mixed results. I also used to work for a company that made a product called MindAlign (which looks like it has been frozen in time since 2004). In every case, these services were initially popular and then people drifted away to other tools such as AOL Instant Messenger (AIM), Yahoo! Instant Messenger (YIM), Microsoft Messenger, and Skype. People preferred consumer chat services because you can also use them to communicate with your non-work friends. Nobody wants to run more software on their computer than they need to.

Times have changed. YIM and AIM are basically irrelevant only to be replaced by tools like Apple Messages, WhatsApp, and Viber. But I think that there are bigger differences in play.

Smartphones have conditioned us to multiple channels

Now pretty much everyone runs at least two computers: a workstation on our desk and a personal computer in our pocket (our smartphone). These two computers have different roles. Your workstation is very clearly for work and your smartphone is focused on digital communications. The smartphone has the best chat network of all (SMS because it is ubiquitous) and it is easier to use now that we have a keyboard. The new chat services (WhatsApp, Viber, Apple Messages, Facebook Messenger) are all focused on the smartphone market.

Chat-based collaboration tools like HipChat don't have to compete with personal messaging services. It is easier for them to coexist because they live on separate devices.

Twitter and Facebook have built new habits

Twitter and Facebook have had a major impact on how we consume information. We are now much better at handling rapidly flowing feeds of information. We are less intimidated by the volume and we have built habits around scanning back since we last checked. As senders we have built habits around posting things multiple times for people who access different stretches of the timeline.

These skills make it easier to handle group chat services like IRC and now HipChat/Slack/Flowdock.

Integrations make chat collaboration tools more powerful

I know that IRC bots have been around for ages but the new breed of chat-collaboration tools have an amazing collection of integrations. After setting up HipChat, it was really easy to hook in the other tools that we use: Bitbucket, Codeship, and ZenDesk. Now that I am better at handling feeds, it is nice to have all of these notifications in one place other than my email inbox. My hope is that email can be used less for notifications and just for messages that I need to respond to. That may drive email volume down.

Why change?

As a distributed team that does better with written communication than voice, we rely heavily on chat. Skype was good for 1 on 1 chats but not so great for group chats because it is difficult to get back into a group chat and scan the latest if you closed the window. With HipChat, many of the conversations that used to be 1 on 1 are in an open forum and there is an open invitation to eavesdrop and chime in. It feels a lot more like an office where people are co-located. We even greet each other when we log on.

But the biggest win is in the integrations. Part of that is having notifications in one shared space. It's like an information radiator in a physical office. Everyone can see it and, when something changes, everyone can talk about it. For example, when we get a ZenDesk ticket notification, everyone sees it at the same time and we can chat about who is going to take it and how to resolve it.

But there is more to it than centralization. I feel the incentive to write better Git commit messages when I know they will go into the stream. People are naturally more thorough and provide more context when writing for a larger audience. Then, if our continuous integration system (Codeship) raises an error, everyone in the room can get complete context of what the code change was, who did it, and the thinking behind it.

A chat collaboration service like HipChat (or others) has huge advantages over tools like Skype. It is especially helpful for us because we are a distributed team; but even in a co-located work environment, chat collaboration could bring the benefits of an open floor plan without the downside. If you really want to focus on something, you can mute the conversation by shutting down the app and catch up when you come back up for air.

Back to Blogger

2015-01-07T16:23:00.001-05:00

In case you noticed something different, I moved this blog back onto the Blogger platform. Actually, Blogger is where Content Here started back in 2004 (Wow! A little over 11 years ago!). Over the intervening years, I converted the site to Wordpress and hosted it on a number of different providers. Some of the formatting shows that the posts are a little worse for wear. And I need to do some theming work. If you notice any other major problems, let me know.

Data ownership and control were the primary reasons for moving off of Blogger. When my website was a core part of my consulting business, $20.00 per month seemed worth it. Now that blogging is back to being a hobby and Google has a "Data Liberation Policy," Blogger makes more sense.

Moving from WordPress to Blogger definitely feels like going against the grain but this article "How to Move Your Blog from WordPress to Blogger" gave excellent instructions plus a good explanation of why you would want to do it.

In addition to great utilities for both Blogger and Wordpress, one of the things that made migration easier was that I hosted all of my images and files on Flickr and other sites. That means that there was less to move.

My experience so far is that Blogger seems like a less cared for part of the Google ecosystem. It's clunky when compared to Wordpress or other web content management systems that I have used. I am sure that Google+ (and before that Google Wave) have consumed most of the attention. I can't imagine that Google would kill blogger, but if they do, there is always Google Takeout.

Nan, you are not a number

2014-12-10T02:06:00.000-05:00

Here is a little programming oddity that we ran across yesterday.

onDemand has a number of downloadable Excel reports. To generate a useful Excel file, it is important to tell the Excel library what data type to make each cell. To facilitate this, we had a little utility function called is_float:


def is_float(data):

    try:
        float(data)
        return True
    except Exception:
        return False

That seemed reasonable enough and it worked fine for quite some time. But then we had this customer named Nan (thanks for the business Nan!). The problem with the name Nan is that float('Nan') doesn't return a ValueError like float('Bob'). float('Nan') successfully returns a float object with a value of 'nan.' The reason for this is that Nan, in addition to a being fairly common name (I went to school with a girl named Nan), is Python shorthand for a "Not a Number." Python's float function interpreted the input 'Nan' as an attempt to create a float object with a value of 'nan'. This caused our logic to try to tell the Excel library that 'Nan' was a number and that created an error. Incidentally, we would have had the same problem with someone named "Inf," which is Python shorthand for infinity.
In case anyone is curious, the fix for this was quite simple:


def is_float(data):

    try:
        int(float(data))
        return True
    except Exception:
        return False

The int function doesn't try to be as clever. It rejects cheeky floats like nan and inf. You learn something new every day!

Priorities

2014-12-08T08:27:00.000-05:00

Prioritizing is hard when other people's requests fight for your attention. It is stressful. You feel attacked; and when you constantly shift your priorities in response to whoever cries the loudest, you get nothing done and you feel defeated. As hard as it is to prioritize your own time, prioritizing what to improve in a product is even harder. The decisions you make on a product have such a large impact. Living under this stress of competing priorities is the life of a product manager. Here are some tricks that I learned.

Create and publish a model for prioritization.
My prioritization framework looks like this. Being transparent about how you prioritize serves three functions: it sets expectations; it encourages stakeholders to express their requests in terms that you can easily evaluate; and it forces you to adhere to your own rules.
Don't elevate the priority of one request. Push everything else down.
It is easy to fall into a cycle of urgency inflation where each request tries to one-up the others in priority. Hysteria builds and you go into reaction mode as you try to keep up. When I feel like this, I try to visualize calmly but firmly pushing other requests down. You only have so much capacity. The highest priority thing should be whatever you are working on right now. It can't get any higher than that. Everything else will have to wait. It feels empowering to actively push requests down to make room for the one request that cannot be deferred. The alternative is passively accepting every request's own self stated importance. That feels horrible.
Group niggling little things into a single item.
One risk of prioritization is that some of the little things never get done. Individually, these details never get to the top of the stack. But in aggregate, they do matter. User experience is all about the details — sanding down the snags that get in the way of delight. To solve this, I like to group some of these requests together to give them a fighting chance against some of the larger initiatives.
Strive for continuous improvement rather than immediate perfection.
Your application is not perfect today and, no matter what you do, it will not be perfect next month. Rather that succumbing to the pressure of immediate perfection, focus on continuous improvement. One of my favorite articles about product management is "Make it Suck Less." While this sounds like an overly humble goal, software would be a whole lot better if every application was managed on this principle. Besides, if you achieved perfection, your job as a product manager would be over.
Take a moment to celebrate your achievements.
After you launch a new feature, resist the temptation to immediately jump to the next thing. Get closure by reflecting on what you accomplished. This will help in two ways: it will get you off the treadmill for a moment to enjoy your success; and it will allow you to evaluate what efforts have yielded the greatest impact so that you can be even more effective with your prioritization. Personally, I find the best time for this reflection is when reviewing release notes before publication and when preparing for a team retrospective.

These practices work for me in product managing my own time. Hopefully you will find them useful too.

Too Dry Anti-Pattern

2014-09-22T12:18:00.000-04:00

I do a lot of code reviews. On average, I probably spend an hour a day looking at diffs. I find this an efficient use of time because I frequently spot bugs that wouldn't be revealed by regular testing. I can also prevent implementations that will create obstacles as we progress through the road map.

One of the anti-patterns that I have started to notice is what I call the "Too DRY Anti-Pattern." For the uninitiated, DRY stands for "Don't Repeat Yourself". It is a primary tenet in one of my favorite books: The Pragmatic Programmer: From Journeyman to Master. Keeping your code DRY means using methods and functions rather than copying and pasting code and not storing the same information in multiple places. I have written about DRY in terms of content management in this blog before.

The Too DRY anti-pattern starts with the good intention of keeping the code DRY. The developer creates a function or method to avoid having the same code exist in lots of places. However, over time the developer starts to use that function in places that do not quite fit. The function gets more parameters and has increasingly complex internal logic to control its behavior in different cases. Too DRY functions are easy to spot. They have lots of intricate if-then logic that try to address a wide diversity of usage.

A counter-weight to the Too DRY anti-pattern is the Unix philosophy of doing "one thing and doing it well." When you run into a Too DRY function, use the Unix "one thing" philosophy to break it down. Perhaps create smaller functions that do specific elements of the larger Too Dry function and then have different functions that use those building blocks in different ways. Also, repeating code isn't always a bad thing if the code is small and performs a discrete function. For example, if you have some code that creates an object and sets its properties, it is OK to have similar instances of this logic if the properties need to be set to different values.

Like all things, best practices need to be applied thoughtfully rather than as rigid rules. So keep your code DRY, but not at the expense of simplicity.