I’ve always been interested in software, and when the opportunity arose to pivot my career from being a lawyer to become a 'product owner', I jumped on it. The new role involved developing software for lawyers and our clients – something I’ve been doing now for the last 18 months.
Before my product-owner role started, I was a full-time lawyer. For the previous 10 years, my academic life and career had pretty much revolved around law. And working as a lawyer, I probably squeezed eight working years into five calendar ones.
All of this means that I accumulated a fair degree of experience in what I was doing. So when it came to building software products for lawyers, I naturally thought I knew exactly what lawyers needed. I didn’t need to spend excessive amounts of time talking to other lawyers – wasn’t it my job to define what their requirements are?
The problem was that, although I was clued up on what I needed, I wasn’t necessarily clued up on what everybody else needed. It meant that the product came in with a number of biases based on my behaviour. In other words, it worked well for me but less well for my colleagues in other areas of the business.
The bias I had introduced was exacerbated when there was insufficient engagement following the first release of the product. I knew exactly how to operate the detailed areas of the product – no surprise given the amount of time I had spent building it. But when it came to fresh-faced users, they found things complicated. And this would have become a real problem had we only discovered this further down the line – after a great deal of work had already been done in building the product.
You always get a 'triple whammy' when you have to change things significantly in software. The first thing is that you have to spend time thinking about what you are going to change. The second thing is that you have to spend time undoing your previous work. The third thing is that you have essentially wasted time and effort building something that didn’t work.
The last of those is unavoidable in many situations. But the key point is that you should minimise the amount of time you spend on that stage. If you can filter out the problems by talking through sketches with people, you’ve invested maybe 30 minutes of sketching. But if you filter them out only at the stage where you have developed code, you have invested weeks, possibly months of work.
The moral of the story is this: speak to your users at all stages of the product – not just at the start but throughout. And try to find out problems sooner rather than later, so that you don’t spend too much time on things that don’t work.
