Jogs vs Sprints — A product team backstory
This was one of the comments on our previous post: Customer-Driven Development — A case study with Luke Chircop, Product Lead at Shedd. When I read the comment, I realised that we needed to show the other side of building great product teams — the messy side, the failures and the challenges that product leaders face while trying to find better ways to work together and drive their product forward. So we went back to Shedd and interviewed their Head of Product, Mark James.
Getting his inspiration from Basecamp, Mark shares the challenges behind adopting and adapting product management practices and the compromises that need to be made when introducing new processes.
Sofia: As a quick background for those who haven’t read the case study yet, a jog, in the context of product development, is a six to eight-week period of intense product development where the work is broken down into two to three-week batches. They typically involve one release followed by two weeks of refresh during which the product and engineering teams can work on whatever they want to as long as it contributes to the business. We got a ton of questions about the concept of jogs vs sprints before and for many it seemed too good to be true so we wanted to go a bit deeper and understand the challenges behind implementing this way of working. So, Mark, please tell us a bit about yourself and about the origin of this concept.
Mark: Shedd is my 39th employer. I left school with no qualifications. I was homeless and I didn’t know what I wanted to do with my life for many years. I worked on building sites, in McDonald’s, as a courier. I had more jobs than I can remember. Then I fell into web design. That became my career. My background was originally in front end, mainly in a design capacity. I went on to become Global Head of Design and then Global Head of UX for various companies. I’m now Head of Product at Shedd.
I’d worked with the co-founders of Shedd about three years ago and had a very good relationship with them. They asked me to come back to help them with their product. Having developed a startup by then, I now had a much better idea — beyond design and UX — of what it takes to build a product. At Shedd, I could immediately add lots of value in terms of structure and validating hypotheses. I could gauge when to use lean and when not to, as well as contribute lots to design and user experience. At the time, the company had no designers or UX people. It was just a bunch of engineers and marketers. I knew it was going to be easy for me to do an okay job. I then hired Luke and Eleonora, Lead of product and UX Research, who are so good they make me look stupid, which is actually great.
When I joined Shedd, they were already working in two-week sprints but they didn’t know whether the time was being spent wisely or not. Gradually, we built up a stronger research function and a customer problem backlog. We also came up with some ideas that customers probably wouldn’t have thought of.
At this time, I’d been following Basecamp and how they were interpreting the concept of cycles, so a lot of what we did was copied from them. The way it works is that people pitch ideas and the founders and the strategy director decide which of those ideas go forward. They then work on those ideas for a specified period of time — normally six weeks — in very small teams of typically three people, which I really like because every person is delivering value to customers. If we’ve got lots of business people and scrum masters and marketers, that’s okay, but none of those people directly deliver value to customers. Designers, engineers and user experience architects are constantly building for people so I was very keen on having these really small teams where there is no product owner. The designer or the UX person acts as the product owner. The teams are so small they don’t need a scrum master and they can work autonomously on solving a problem in a set period of time or even solve multiple problems. This is all described by Basecamp, so don’t listen to me. Read what they’ve written.
Another concept we adapted from Basecamp was the idea that after a cycle you’d have two weeks of complete freedom. We call it a refresh. During the refresh you must work on something that is valuable to you and the business and it must be interesting. At the end of the two weeks, you tell us what you’ve done and we plan for the next jog.
Everything has been stolen from Basecamp, but we tweaked some of the things because they weren’t working for us. For example, Basecamp really understand their products because they’ve been working on them for over 15 years. Most of the engineering and design folks know what the problems are and they already built out most of the core features for the products so there’s not a lot of moonshots. They don’t have a lot of difficulty solving problems whereas we often start out with no clear idea.
We’ve adjusted the refresh period a ton. It’s taken us a while to be able to finish the jog on time so we have the whole two weeks to refresh. Often, the jog will eat into the refresh because we spend so much time fixing bugs and planning the next jog. The concept does have its challenges since it seems to work better for more mature products like Basecamp.
Sofia: How did you go about implementing this? Did you experience any resistance from the founders and the engineers?
Mark: I’m lucky in that I’m quite persuasive. When I arrived at Shedd, I didn’t change anything for a month. I just observed even though I had lots of ideas in my head. I then held a retrospective where we drew up a list of all the problems and their solutions. After that, getting buy-in was reasonably easy.
There were some people in the organization who were very skeptical about the refresh part of the jog and it’s understandable — for every single jog we’ve done, the refresh has been problematic. Despite our best efforts, we’ve been doing this since April-May and not hit one jog where the refresh time has been fully spent on that. Engineers end up fixing bugs instead of having all this exploratory time and then too much time gets spent on planning the next jog, so we’re still learning a lot.
Sofia: How has the jog evolved giving the current challenges with the refresh period?
Mark: The delay started off taking about 75% of the refresh and now they’re are taking about 25% of it so we’re definitely getting better.
Another challenge is balancing longer-term strategic efforts — we call it ‘belief-related work’ — and smaller tactical work. Let me take a step back. At Shedd, we have a very specific framework for decision making. The company was built on four core values — we call them ‘roots’. These values, which are essentially the values of the co-founders, have borne the ‘why’ or the purpose of the organization. Our purpose is to ‘make better use of the world’s possessions’. These are things that we believe in based on our experience in the industry and the research we’ve conducted. For example, going from our believe of building for local into the belief of building for global audiences. Every piece of work that we do is a ‘bet’ that’s designed to prove or disprove one of those core beliefs. They tend to be big, strategic pieces of work like international shipping, which is related to our belief that ‘we’re not local’. It could be interplanetary shipping in six years’ time if Elon gets his way. The bets are normally big pieces of work that require a lot of deep thinking. Balancing those bets against the 47 bugs that have been on the platform for six months is tricky. One thing we’ve thought of doing is creating two teams. The first team work on strategic development while the second team, mostly made up of new hires, do ‘gardening’. Gardening is pruning and fertilizing — building foundations, getting rid of old bets that didn’t work and fixing bugs. Eventually, the gardeners graduate to the strategic team.
Sofia: It sounds like you’ve been experimenting and iterating a lot on your processes. What’s your advice to other product teams that are trying to evolve the way they work? How can they get their team onboard?
Mark: My advice would be to plant the seeds early and over-communicate what you’re doing and why. It’s never about the technicalities of whether it’s a six or seven-week jog. It’s about telling people the story, taking them on the same journey that you’ve been on and selling the vision.
The specifics that are relevant to us won’t be relevant to another organization so it’s pointless me saying you should base the length of your refresh on one third of the length of your jog. That’s only relevant to us. I would say, do a good job of PR-ing and selling the vision.
Another tip would be to mitigate the anxiety of change by saying,‘This new process is a guess. It’s our best guess today. At the end of it we’re going to change a load of stuff. We’ll have made loads of mistakes and that’s totally okay. As long as we learn and we iterate, then we’re all good.’ That way we can reassure anyone who has objections to the idea. They’ll see that we’ll figure out if we were right or wrong and then we’ll iterate.
If you liked this post then please give us a clap 👏🏻 so other people can find it too.
If you’re interested in learning more about customer-driven development, visit us here https://getenjoyhq.com/
