I seem to have been running a lot of retrospectives lately. And yes, I just used an Oxford comma. Get over it.
In case you don’t know what that means, a retrospective (or a ‘retro’ for short) is a meeting-come-workshop where you look back on work you’ve done, as a team, and try to identify ways you could be better in future.
In agile methodologies, you can hold retros pretty regularly. With Scrum, you’d hold one at the end of every sprint – typically every 2 weeks – so you can get feedback quickly and adjust course immediately.
Think guiding a canoe through rapids; if you can’t change course quickly, you are going to hit a rock (a fairly common metaphor for retros uses a sailboat, as above) pretty soon, and pretty fatally.
One year ago I made the move from the Scottish Businesses Marketing team and started my new life stepping into the unknown, as a Product Owner in the Export Service Design team. Now, I have one foot in the SDI Trade Service team and the other in Service Design.
Officially, the Product Owner (PO) is “responsible for maximising the value of the product and the work of the development team”. This is a new role for the organisation as Product Owner is essentially a role coined from the agile way to manage a project, usually software development, called Scrum.
I’d always though of myself as a bit of a geek with a passion for web and digital, so I was excited to be able to use my export marketing experience and customer insight to tackle this new challenge and really get up close and personal with our end users.
One year on, I thought I’d share and list the 10 lessons that have stuck with me.
Reading Time: 5minutesOn Friday 6 November the Digital First Service Design team packed up post-its, whiteboards, sharpie pens and blue tac from our Paisley offices and set up shop at the UKTI Explore Export event in Edinburgh.
We’ve been busy over the last few months, developing and launching the new Export Health Check.
In September we launched our first version of the tool on the SE website. Based on results of customer testing on Version 1, we made changes to the design and how the content is displayed on both desktop and mobile versions.
So, it was time to give Version 2 a thorough road test and get real-time feedback from exactly the customers that we built the tool for. The Explore Export event gave us the opportunity to get in front of more than 200 of those customers in one hit.
Getting to know and understand our customers is fundamental to my role as Export Product Owner. It’s my job to represent their voice in all the digital export services we develop.
It was difficult for him until he eventually started to see results. This blog is about a similar leap of faith.
Think about these two statements…
If you are truly committed to building customer value, then you will be building what the customer wants (needs) and the customer will be delighted. Because of this they will buy the product or even buy more of the product, while increasing the likelihood of remaining loyal to you.
If you are truly committed to empowering your employees, then you will provide a work environment where they feel ownership of their work and can make their own decisions, and they will be more motivated to activate their brainpower, improving morale and increasing the likelihood that they will go the extra mile to create a quality product. *
These are mutually inclusive (and recursive) sentiments, and the answer to how they are done can be summarised as:
Reading Time: 4minutesNo this is not a phone commercial. Yesterday was great. On the train in to work I had a chat with a friend who does similar work to myself. A couple of things he said struck a chord and I am going to implement them at work.
In work we had a director come out and chat with us about future plans, limitations and opportunities and generally make us feel involved. We then had a large group of managers out to Paisley and had a really good chat. We talked about how we were doing things, and what lessons could be applied across the business.
At lunch I called my sister and we caught up about family stuff.
All of these positive experiences would have been destroyed by doing them as word documents. A nice word document is good for audit but it would have been time consuming, scope limiting and ultimately never read by anyone. In others words “Waste”. It would have slowed down sharing of info and ideas and also supported behaviours such as people disengaging if they were not the ones writing the document.
In the afternoon I tried in vain to finish a document on Future Online Diagnostics Options. I have been finding excuses to not finish this document for days. That is pretty unusual for us at Paisley but it does happen. It usually means that subconsciously we are rejecting something as being waste or at least sub-optimal. I had done all the research and I am passionate about the subject but I still couldn’t get the document finished. In the end David and I grabbed a few whiteboards and drew out the various options on them…….and then we had a chat about them. In truth the chat we had fleshed out at least as many ideas as I had gathered in my research. It also highlighted new areas that up till now had been “nagging doubts” which we had not fully explored.
Reading Time: 5minutesWe’ve been experimenting with mood maps to record customers’ emotions while they use the prototypes we test with them. The results are revealing …
Mood maps are pretty simple graphs of emotion over time. You just observe someone interacting with the app or content you are developing and plot how positive or negative their emotions are for the duration of the test.
Reading Time: 3minutesI’m part of the digital first project, the team that’s looking into new ways of working that will help Scottish Enterprise improve its projects’ performance.
One of the things the team is doing is a 12-week training course on Value, Flow, Quality. That probably doesn’t mean much to most people, but basically it’s a methodology we can use to organise ourselves and our work to deliver value to our customers, quickly and flexibly.
One of the things we looked at in our first session was why IT and software projects regularly fail (by some measures, only one project in three is successful).