In my last post I examined some lessons learned in driving a change in career. Sticking with the subject of driving change, in this post I examine some lessons learned from my recent work initiating a change in product direction.
Since I joined my current company in 2019 the end user capabilities of my product have been almost exclusively served through a desktop application. This type of application provides users with a lot of power, but it is challenging to develop and much harder to restyle than a web-based application. While the easy option would have been to continue developing this capability, we'd already seen some early signs of negative feedback based on perception compared to a web product. It was apparent to us as a company that we needed a shift in direction, but the challenge was that so much of the user experience was tied up in this application that there wasn't a clear path to the web without a major rewrite.
Re-evaluating the product goals
The first step to initiate change was to evaluate our existing user goals and whether our current approach was the appropriate way to achieve them. The product is based on a highly powerful and flexible data engine and the user experience does expose that strong data capability to the user. From speaking to customers in an early training course it seemed that they were less comfortable with exposure to database concepts than was needed to get the best from the software. I hypothesised that a shift of data skills out of marketing teams, and the advent of an increased number of digital marketing channels, had shifted the goalposts in terms of our target audience.
Further research with our team helped to validate this hypothesis.
- Listing out and profiling a representative set of our user base with the customer services team gave a clear majority group of users who had stronger creative and testing skills but were less comfortable with database concepts
- Running a whole company workshop to create some representative proto-personas was a revealing step which opened up the discussion around our user base and the importance of working towards a simpler user experience
- Attending more training courses and speaking to new users provided invaluable insights into their early experiences of using the product and which concepts they found challenging
- Conducting research interviews of both existing users and representatives from our target market reinforced the validity of our personas and the jobs that those roles were using our software to achieve
The outputs of this process provided the justification I needed to drive a change not only for technical reasons, but also to push towards a new, simpler customer experience.
A strategy for change
Some larger companies needing a product refresh will spin up a parallel team and instigate a rewrite in a new stack (see my post on the perils of rewrites for the problems that this can present). With a small development team actively supporting live software this was simply not an option for us.
What we needed was a strategy that allowed us to progress towards a different shape in a way that didn't undermine the value that we were already delivering. We needed to shift the focus of our application away from the desktop, and reduce the need for understanding database concepts, while maintaining a valuable product shape along the way. After all, identifying the need for a change in direction is great but it is of little use if the path from source to destination is not navigable.
Incremental Steps
Trying to leap from starting position to end goal without any valuable steps in between leaves you very exposed if you fail to hit that goal first time. A key for me in driving effective change, in pretty much any context, is through the agile principle of delivering valuable, achievable increments.
- When moving to new technology the first deliveries may be quite limited when compared to existing features, but this simple start is justified if it establishes a solid point from which to drive a change
- Showing a small amount of value regularly provides stakeholders with evidence of your progress and it's surprising how quickly incremental value can grow
- Achieving frequent valuable steps is also more motivational for the team than aiming for a distant goal
- Finally if the goalposts move mid-transition you always have a solid current position as a base to pivot from to shift direction
The strategy I settled on in this case was to provide new turnkey reporting capabilities in the web. This would provide a slice of important value, reduce the need to use more raw data tools and maintain a coherent platform with each step taken. Keeping these coherent increments is a challenge but it means we're finding the balance between effectively delivering new value and driving strategic change at the same time.
Prioritise Aggressively
Emergent product decisions often involve a trade off between long term plans and tactical needs. Too often the result is that your dreams of change remain just that, at the expense of a constant stream of emergent priorities. It can be challenging but achieving each valuable change increment may require deferring other needs that others may see as more important at the time.
I'd argue that there's no perfect model for making these decisions. Deferring anything that impacts on the change you're trying to achieve without incurring significant cost elsewhere will prevent your efforts from stalling, but defer too much and existing customers or stakeholders may get frustrated. Having a strategic goal in mind gives you a framework for decision making that allows you to make sure you are always moving in the right general direction. Again delivering in increments is also key here as it means that you can allow time to take a breath and focus on addressing some tactical concerns between each step.
Trust you can get there
The biggest fear faced by most senior software professionals I know is getting it wrong. Despite all our efforts to base decisions on evidence, it's clear that for anyone having to make significant strategic decisions there's rarely a universal right answer on when and how to instigate change (If there was then why are so many successful entrepreneurs' closets full of failures ). As the numerous tales of great products that went stale will tell you, not making the decision to change can be the worst decision of all. Even so, in the early stages the idea of achieving any sizeable impact can feel a distant and intimidating prospect.
I find that if you build a great teams and get them on board with a vision of what you can achieve, then you can trust in your collective ability to deliver. This is for the simple reason that a great team will challenge your ideas and simply won't be fully engaged if they don't believe they are achievable. While there are no promises in the outcome, if you are seeing genuine engagement behind your strategy then there's every reason to be confident that you can elicit real change. As we release the first capabilities in our entirely new web application this month after a stupendous effort from my team, this is something I can attest to first hand.
References
As a side note, I know that some are advocating that the Jobs To Be Done (JTBD) framework has rendered proto-personas redundant. In this case I believe that personas provided a far more effective mechanism to communicate our situation and convey the need to rethink our user experience based on the skills and desires of our users - this article provides a useful reference point that supports my experience on this https://www.nngroup.com/articles/personas-jobs-be-done/
Photo by Benjamin Combs on Unsplash
Post a Comment