Customer-Driven Development — A Case Study with Luke Chircop, Product Lead at Shedd.

We had the opportunity to chat with Luke Chircop, Product Lead at Shedd. Luke shared his experience helping his organisation become more customer-driven and his advice on how to involve other team members in the process.

Luke Chircop Shedd

Sofia: Luke, can you tell us a bit about you and Shedd?

Luke: So I started out in the tech scene as a QA Analyst while I was studying computer science, which then led me to work as an engineer for a few years. I quickly got interested in psychology and behavioural sciences, so I went on to study Human-Computer Interaction. I started working as UX researcher and a designer in agencies and client side. Without having planned for all of this, I ended up developing a deep understanding of every role in a scrum team.

I’m the Product Lead here at Shedd, joining 6 months ago. Shedd’s purpose is ‘To make better use of the world’s possessions’. Currently we are trying to do this by helping women buy and sell second-hand fashion, but it didn’t start this way. It actually started as a local service that enabled people borrow or trade under-utilized items like tools or watches within the same building or neighborhood. However we discovered that a lot users were trying to sell their handbags on the platform. We were like, “No! We don’t want your handbags. Trade your drills!” And so we started banning these users because they were not using our platform in the way we’d intended. Following some research we found that on average 54% of a woman’s wardrobe is only worn once or never even used at all. So we pivoted the whole business with the core focus now on buying and selling women’s pre-adored fashion.

customer driven development at shedd

Sofia: How did you go about starting the process of aligning the business around the customer?

Luke: Shedd is really open to experimentation, from the founders throughout the company. So getting buy-in was pretty simple, and the insights and benefits we get from centralising our qualitative data was quite an easy sell anyway! But we were very lucky, as 7 months ago there was no product team at Shedd — so between Mark James, Eleonora Zucconi and me we pretty much had a blank slate to start from.

In terms of our process, Shedd operates in 5 countries, all in different languages which brings its own challenges. Our customer support team is key to this process, not only tagging all the localised feedback but also curating our taxonomy of tags. Our current data sources are Android and iOS app reviews, surveys, helpdesk tickets, ZenDesk chats, feedback emails and user research. Each week, we get together and review the top issues from the last 7 days. Enabling the product team to quickly focus on understanding particular problems, and complementing our findings with customer interviews and other research techniques.

customer driven development at shedd

Sofia: What is your advice for product teams that want to become more customer focused?

I think in most companies I have seen two common problems. One issue is having very rich isolated pockets of information across the organization and no one is sharing that information or they can’t easily act on it. The other, as a consequence of the first, is that decisions get made entirely on quantitative data. Everyone’s trying to run analysis, but not everyone’s actually sharing it, so solutions end up being local optimisations.

If you are starting from scratch I would say, gather qualitative data across the customer facing teams in your organisation. So, start speaking to the customer support teams as they are usually sitting on gold dust. Don’t worry about going through levels of hierarchy, just start speaking to individuals from those teams. You can then start triangulating insights, and hopefully find one or two nuggets of really, really valuable and actionable insight. Take those insights and share them with decision makers or in your next meeting. Once you have people bought into the idea of using qualitative data, slowly but surely, more people will start doing the same and you can start designing a better process.

At Shedd, getting all of that insight together, or rather trying to read all of the insight and accessing the different sources was taking the best part of a week. Then to try and do analysis on it was almost impossible. So, I started looking for solutions and this is how I came across EnjoyHQ. It offered exactly the right approach we needed for the problems we had. We are now able to not only easily identify qualitative customer problems, but also understand adjacent problems.

Sofia: In previous conversations you mentioned some very interesting ways your product team works together, could you share some of that with us?

Luke: Sure, for example, we don’t sprint, we jog. As my colleague put it “Who likes sprinting all the time” :) We typically have six to eight weeks of intense work and within the Jog we breakdown our work into 2–3 week Batches which typically involve 1 release. In terms of roadmaps, we don’t really have one. We have a customer problem backlog more than a feature roadmap. The solution then gets defined as part of the jog; through user research, design studios, usability testing etc. This then becomes our short term roadmap, so to speak.

So at the moment, our Jog goal is to reposition the value of Shedd in the United Arab Emirates. There are lots of big and small features within that but we tackle them as a whole theme. After the Jog, we have a 2 week Refresh where people can work on whatever they they feel will be of benefit to the business, and start preparing for the next Jog.

customer driven development at shedd

Our ideal state, is that as we work through our customer problem backlog we start seeing correlations between our EnjoyHQ tags and our app releases. We are not there yet but I can’t wait!