Developers love to launch. It’s the culmination of weeks or months of work (if it’s years, you better be building an operating system) and the public is about to see what you’ve created. But it’s far from the end of your big release.
And if you’re juggling multiple projects, it’s tempting to wipe your hands clean after a site or app launches, and change your full focus to a new project. This is especially true when your team has truly done their best to maintain quality throughout the design and development process. You’ve thought of everything, tested with a small group of trusted users, and you only had so much time booked in the calendar, so you call it done.
pressLaunchButton();
onToNextProject();What may be missing from your schedule is the “.1 release”.
A recent launch of an intranet portal is a great example. Our team did a fantastic job of innovating during the design & dev phases, as well as leveraging some cool new interaction methods and technical integrations (new to us anyway!) We estimated our development time reasonably well, and set the expectations with ourselves that we were delivering a 1.0 release, and we’d come back soon to address all of the experiential things that we knew users would have to tolerate for a bit (e.g., slower-than-ideal authentication/authorization on first load) while we focused on a different project with a totally different set of end users.
That was almost 6 months ago.
The problem is that because there was another high-priority project waiting in the queue, we consciously skipped the .1 release of the previous project. But the .1 release is the release where you monitor the application and the experience your users are having, and respond to their needs quickly. The .1 release is where we make good on all those IOUs we made while disclaiming “we must deliver something now, we committed to a date and we’ll get in trouble if we miss it”, and that each of their individual needs will be addressed in the next version. This is all fairly standard and valid, as long as you actually plan the time in your project schedule necessary to listen to your users and improve their experience.
When we constantly deliver at 100% (or greater), we don’t give ourselves enough buffer. Not just setting aside time to mitigate known and unknown risks throughout a project (the latter is frequently forgotten), but buffer to sit back and listen after a major release. We should have confidence that we couldn’t possibly have gotten everything perfect for every user, so allocating time to ensure that even their smaller needs are addressed before we move on to another project is imperative. The small things may determine whether or not a user finds value in your product, and a healthy user growth curve is supported by happy users.
The .1 Release is the “Listening Release”
Once you’ve launched that first or other major release, celebrate the win! Get a good night’s sleep. Then come to work and just listen. Certainly we’ve all built multiple feedback loops into our applications, right? We have New Relic analytics for our server performance, exceptions logged to a database for analysis, a feedback form and forums for users to contact us … but why did we build all of that into our app in the first place? We did so to enable us to know more about how our app is doing, and more importantly how our users are doing, so that we could take action where necessary. Listening but failing to follow up with improvements and fixes right away could potentially be worse than not listening at all because you’ve set users’ expectations incorrectly.
There are very objective reasons for dedicating time and effort to listen to, and fully understand, your users. Such as meeting expectations better, and being more efficient by avoiding rework. But there’s also an emotional component to the exercise itself — it builds trust with users, and demonstrates a genuine empathy for their needs.
Failing to Listen Guarantees You Are Forever Playing Catch-Up
Most of us don’t get to set all of our own priorities – they are dictated or influenced by customers, managers, colleagues, holiday shopping seasons, and such. We have multiple projects and products in our workshop, and we constantly switch context to whatever is most important right now. And while there are some environments where that works well, context-switching in software development is expensive in terms of time. The constant drumbeat of “deliver, deliver, deliver” often means that important phases of an application’s life cycle get omitted.
Think about who’s priorities we’re catering to when the consequences of delivering later versus earlier are greater than the consequences of not delivering the best experience to our users. (Hint: it’s not your users’ priorities you’re optimizing for …)
When we don’t schedule the time in the project plan to follow up with a .1 release, users feel unheard and abandoned. Sometimes for a long time. Yes, you hit your deadline, and you’re on to put out the next fire (because every project is the most important project, right?) However, we’ve only served our own priorities at the expense of ignoring those of our users. And as long as we continue to release without listening, and without following up immediately with a “listening release”, we are guaranteed to always have a growing backlog and worse, a growing number of frustrated users.
As Ron Swanson said, “Never half-ass two things. Whole-ass one thing.”
A Better Experience for Everyone
And I do mean everyone! The best way to ensure that what you’ve created is actually improving the lives people (because at our core, makers of all disciplines want to build things that impact people) is to release your best work, then take the time to listen to users, set correct expectations, and address their needs as best as you can. Don’t declare “mission accomplished” and move on before your users are happy. This builds trust with your users, which is a very necessary component to user adoption.
Knowing the triple constraint exists in project management, increasing quality isn’t free. But deciding early on that the definition of success is based on a level of quality and user acceptance and not just the delivery date, and that you will spend the additional time and cost required to make users happy will make building and using your product a much more enjoyable experience for everyone.
Just remember who you are ultimately designing for, and spend most of your time serving their needs and priorities.
(Featured image courtesy of Flickr.com/Rumpleteaser)