Every digital company should have at least heard of being agile and delivering lean. These are wonderful things that can enable teams to deliver the right change at the right pace. But how do you make sure that the change is right for your customers and colleagues? Hopefully the below points can help you out here.
1. Make calls based on raw numbers over percentages.
Always know the popular features are and the features people won’t miss. Assessing usage stats in what ever reporting platform you use should take place before any scope decisions are made. Avoid making calls by percentage of use, look at the raw numbers. 1% might still equal thousands of visits or views each week.
2. Are you replacing something or building a shiny new thing?
If you’re rebuilding an existing feature aim to achieve feature parity with the experience you’re replacing. At the very least understand which features must not drop off by assessing your metrics. When introducing a brand new feature, there’s a lot more tolerance about going out light-on and iterating functionality over time.
3. Do you need to refer back to the old experience?
When updating existing features, provide an obvious link back the old experience. Give people time to absorb the new experience and create new mental modals around how it works before taking away access to the experience they got were to.
4. Arm your customer support and social teams with the answers they’ll need.
Think about what’s changing? What’s missing? What’s new? Do you have plans to introduce more scope over time? How will all this impact your users? And most importantly why have you made these calls? The answers to these questions should be conveyed to those who talk directly to customers via support and social channels.
5. Be across the feedback.
Understanding customer feedback is paramount. Feedback will always spike when change is introduced. It’ll mostly be negative, sometimes constructive and on the odd occasion you might even get a compliment. Don’t be disheartened by this, people aren’t inclined to pipe up just to say well done. If they’re happy, you won’t usually hear from them.
Each customer has their own story about how they use your product to solve their real world problems. Know the edge cases and look for patterns, does what you’ve delivered provide a solution for these?
6. Have your iteration plan ready.
We tend to move on (after a brief celebration) to the next epic on a road map as soon as we deploy a feature. This can be a mistake, especially if you’re replacing a feature without all the bells and whistles that a previous version had. You need to build into your road map subsequent releases of a feature that take into consideration market feedback. Always remember that the first deployment of a product is only the beginning of it’s life.
If and when people complain about something you’ve changed, ensure that you’re across it and that you have the ability to reply these people once a subsequent update to the feature addresses their concern. You can convert them into passionate followers with this kind of attention. You’re showing them that you really care about their needs by address their issue and getting back to the them about it. Even if you don’t plan to address a customers concern, letting them know this is far better then ignoring them.
7. Split test if you can.
A/B testing should be best practice is this day and age, thats not to say it’s easy though, especially when working with an older site that’s already on its knees performance wise. Essentially we are always striving for some sort of conversion, be it a purchase, upgrade, reveal, save, submit, view, call, create. The elements we use to entice people to partake in these actions can all be candidates for split testing. If we aren’t adding a little science around understanding which variation of an experience ensures the best conversion of these actions, then we are merely assuming that the single experience delivered will provide the best outcomes.
8. Strive for feature parity.
People now expect feature parity well beyond the desktop. Mobile devices and data networks are now capable of facilitating this expectation. From a delivery point of view you want to be making the right fundamental decisions up front, before anything is built. Ask yourself – what will give you and your team the best chance of providing a consistent multi-device experience? It might be worth wearing more initial overhead to build out a responsive web app. It could take you longer to get an MVP to market, but this is an expectation you can manage. Once deployed the advantage kicks in with efficiencies in effort when iterating for different device dimensions and resolutions from a single app.
9. Don’t get carried away with internal objectives.
Day in, day out you will be inundated and influenced by the language and behaviour that occurs with in the walls of your company building. This is all good, but don’t let this get you too focussed on internal definitions of success. Targets in visits, time on site, engagement, sign-ins, whatever it is – these are all means-to-an-end and can be subjective. The true definition of success is harder to measure or even define, but it lies within really understanding true real world problems that people encounter (and they may not even realise they encounter them) and providing genuine solutions to these problems. I find that satisfaction survey results and verbatim user feedback are the best barometers as to whether you’re nailing it or not. If you are nailing it here, then the internal objectives that define success should be a by-product.
10. Find the right engagement model.
For me this ones the most important. How do you ensure that you take your colleagues (who aren’t directly apart of your delivery team) along for the ride? Think legal, sales, social, finance, media, security, marketing – they will have opinions and requirements that they’d like you to at least consider.
Do you engage them all at once, in small groups, individually or is it a combination of all of the above? If everyones clear on what’s happening and their individual expectations are being met – good for you! If there’s uncertainty, confusion, people feeling like they’re being left our and worst of all ‘dreaded surprises’ – then you need to change, and fast. The only thing I know for certain is that the model you used for your last project, probably won’t be as applicable to the one you’re doing now. You have to be astute and gauge how much you and your stakeholders are getting out of the current model, then act appropriately.
Lets use marketing as an example. They are working with a third party agency to communicate the value and particulars of your product. However when delivering lean in an agile environment, things can change fast, sometimes daily. This said it’s easy to fall out of sync between the marketing campaign and what’s actually being built. The ideal way to prevent waste and delay here is to convince your marketers to co-locate with your team, so that they are actually apart of the delivery team. But they have their own agendas so this approach might be asking too much.
My fall-back advice is to invite them to stand ups, have a weekly time-slot booked in with them, be on the front foot about keeping them up-to speed on an ad-hoc basis. It also helps if you can give them degrees of certainty regarding certain scope items and go-live dates, so that they can confidently build this information into their campaigns. Even asking your designers to use marketing approved images and copy in concepts and Photoshop files will prevent unnecessary double-handling when the marketing and/or agency designer eventually inherits the files.