Protect Day 0
This is the second in a series of articles about increasing the rate of success in software projects, whose failure rate industry-wide currently is estimated at 70%.
Technology transformation projects by rule involve change. Our ability to manage change has an outsized influence on our ability to be effective at these projects. When conceiving projects, we tend to fix our eyes on a point on the horizon, months after the moment of launch, when everything is running smoothly. But to over-focus on that point of fruition is to doom our chances of ever getting there.
Below are our guiding principles when managing change.
We will consider the user when setting the pace of change.
We know that very broadly, users prefer incremental change to sweeping, all-at-once change. This is at odds with organizations, who often prefer to make large changes and be done with it (wink-wink, nudge-nudge to those who know that change is never really done). We also know that managers and product owners tend to overestimate the user annoyance at repeated change and underestimate the risk of large changes that disorient users. Therefore, we will loudly advocate for smaller, more frequent changes whenever practical.
This ultimately serves the organization and its management as well, as smaller projects are more likely to be successful. The article linked implies internal projects vs. outsourced projects, but we can apply the same principles to both. Although presumably with outsourced projects you can eliminate issues with talent problems, there are still internal issues to contend with. Smaller projects still require careful change management and aren’t immune from internal political machinations, but users are more forgiving if the change is incremental.
We will also use the opportunity of smaller incremental releases, whenever possible, to be strategic about the order of our progress. We will recognize the potential of Incremental change to gather data on user habits and preferences, validate assumptions, and seed data for future endeavors. By gathering data along the way and using it to adjust course when needed, we can make the ultimate whole more successful.
We will communicate clearly and usefully about change.
Surprise changes are harder for users to stomach than expected changes. One of the first questions when change has not been communicated to the user’s liking is often an accusatory “Why didn’t you tell me this was happening?” This response often happens even when users were told it was happening. Yet they genuinely may feel they were unprepared.
To alleviate this, we will be guided by the following principles in our communication:
We will assume users are busy and don’t see every communication. Email open rates are around 20%. A single email is unlikely to accomplish the task. Push notifications and in-app notifications are often dismissed without reading, especially if they are grouped with many others. We will communicate repeatedly, with an escalating level of urgency as the date grows nearer.
We will communicate further in advance if the user needs to take action to prepare. Perhaps they need to reset their password, notify their customers, or change their method of payment. The more challenging the ask of the user, the more advance notice we want to provide. This could be as little as 14 days for a very small ask, or up to a year or more for large, time-consuming asks.
We will prioritize communicating specific information to relevant users. We will avoid sending communications like “Many things are changing! You may or may not be affected.” whenever possible. This may mean needing to store additional information on the change progress of individual users. Where this is needed, we will recognize that the improvement in experience is generally worth the expense.
We will choose useful channels for communication. Email is easy, and makes a lot of sense for office-based users. In-app notifications are even better, especially when combined with the point above about understanding where the user is and customizing their experience to reflect their individual needs. At the same time, users generally don’t appreciate forced tutorials that pop up unbidden to showcase new features. When choosing in-app communications, we will endeavor to make any tutorial or communication something the user can choose to look at when it works for them. For non-office users of apps they may only be in sporadically, other methods such as SMS or push notifications may also make sense. We will prioritize the method(s) most likely to be appreciated by the user when choosing our communication channels.
We will make action easy. If possible, we will link action to tasks the user is already motivated to perform and keep them in the same flow. We will handle possible edge cases to keep them in their flow and maintain a smooth experience.
We will consider what method of training is likely to work for the audience. Again, we will not assume they read the email. We use methods like dismissable tips near the new feature, on-demand videos, and even live trainings for complex items, to ensure users are prepared.
We will optimize the Day 0 experience for what it is, not what it will be.
The excitement of a big vision can cloud the perception of current reality. Users who adopt on the first day to see a nearly empty marketplace, blank knowledgebase or short list of fellow users are likely to feel disappointed. If the grand vision is what has been pitched to them to entice them to join, they are likely to be even more disappointed as the contrast between expectation and reality paints the product or feature in a harsh light.
We will not expect our audience to use their imaginations. If our product requires user generated content or a large audience to be useful, we will explore ways to seed this to provide a valuable Day 0 experience. We understand that users value their time and are unlikely to be back if they feel disappointed in the initial experience. There are many APIs and web scraping options available. We will remember that we must provide a positive experience to the early users if we expect to reach the ultimate goal. This does sometimes require investing in features and data that will not be a part of the platform. Where this is required, we will appreciate it as an investment in building user loyalty.
We will take care with the expectations we set through our pre-launch communications to balance the promise of the ultimate vision with the reality of what it can do immediately. If needed, we’ll chart a path for the plan to get to the vision, but we will always ensure we are providing significant value at the moment of launch. If we’re not, we don’t have an MVF (minimum viable feature).
We will consider the needs of both new and existing users.
New users and users already in the platform have different needs when a new feature is released. For example, if more data is required of the user to experience a new feature, the new user can be seamlessly guided to provide this during onboarding. Existing users, however, will rarely go seek out their settings or profile pages to spontaneously provide new information. Therefore care must be taken to meet the user where they are both in the communication of the feature, and in getting the user to take needed actions to have a good experience.
For new users, we will remember that they just want to get to the good stuff, and we will think long and hard about putting additional steps (aka roadblocks) in their way. Whenever possible, we will work any needed actions into steps they would take anyway, as close as possible to when the action is needed. For example, if we have to ask for a credit card, we will prioritize waiting to do so until the moment the user is trying to make a purchase.
We will also recognize that users already in the platform are often the forgotten ones in change management. We will think through their experience with empathy, taking care to give them choice and connect any actions we are asking them to take to the benefits they will receive. We will bear in mind that although handling their experience costs money, it is usually less expensive to keep current users happy than to go find new ones.
Summary
There is a concept we’ll discuss more in another post about optimizing the emotional peaks of an experience, because they are what people tend to remember. Managed well, the moment of change can be a positive peak experience with a product. Left to chance and good intentions, however, this will never happen. The effort we put into managing the moment of launch of a new platform or feature, and the days that follow, will have a major impact on the success of the project. We will respect the importance of change management and not expect our users to go to heroics to save us from a lack of consideration of their Day 0 experience. We will plan, communicate, optimize and launch with their experience at the moment of change at the forefront.
If you liked this content, you can have articles like this one sent to your inbox regularly, free of charge, by subscribing here.