Author: David

If there’s one thing that’s stuck with me from attending a JTBD interview workshop with Bob Moesta and Greg Engle, it’s this mindset of how to approach customer interviews: You’re trying to uncover patterns across different stories – and not to find the needle in a haystack!

Two weeks ago I participated in a digital JTBD workshop with Bob Moesta and Greg Engle. The workshop was designed for JTBD practitioners who’d had some experience doing this kind of research and wanted to up their interviewing skills. After discovering Bob’s flavour of Jobs-to-be-Done during my parental leave in 2018, I had become enthusiastic for this way of doing product research. But so far, I had been entirely self-taught – based on freely available resources like conference talk recordings, podcasts, blog articles and so on. Since I’d had so much free time during my parental leave, I had enjoyed sifting through a huge mountain of podcast episodes and conference talks. But I know that there are also people who would like to learn about Jobs-to-be-Done, and do so in a more structured way while still leveraging resources that are freely available on the web.

On the face of it, Shape Up is a framework for IT project management. It talks about backlogs, how developers and designers should slice projects and about stubbing an interface to figure out affordances before a complete visual design. Beneath that surface, though, lie basic truths about work and project management that I believe could have tremendous effects on the work in other business functions and teams.

For example, take the notion of No Backlogs. For my work as a product manager, it’s had a couple of consequences. We take on development projects that have a clear end in sight and with a mindset that it’s OK if we only work on this problem for one cycle (= 6 weeks) and are then free move on to something completely else. Or consider the consequences of submitting Pitches to the Betting Table, where a collection of projects for an upcoming cycle of work is bet on. To everyone involved, it is unquestionably clear that there’s only so much we can do in 6 weeks, given the people that we have. There’s things that we believe are worth more resources or less resources. So we specify an “Appetite” for a given project, which is to say: “How many people should work on this for how long, and not longer?”

If we want to do one thing, it’s always clear that this means we will not be doing something else.

In our work as a product and engineering team, these concepts have provided us with such focus and intentionality about what we do and do not work on at any given point in time, that it’s become a basic expectation for me to be working this way.

But a recent interaction at work reminded me that this is not at all the reality for other teams. Even though they don’t call it that, those teams (from functions like marketing, operations or business development) usually operate as if they had a public backlog and are in a constant sprint. Any request that comes in is just added to the list, and when it comes up, is executed. “Yes!” is the default answer to any task.

For their sake, I wish they too would see their time as finite, would see trade-offs in what they work on. This is the power of committing to any time box that constrains you. Without those clearly visible constraints, like a 6-week-cycle, you just say yes and step on the hamster wheel of meaningless, unintentional work. This is also the power of committing to a healthy 40-hour-week. If something comes up that you want to say “Yes!” to, then this means you’ll have to say “No!” to something else you had previously planned.

My time is finite, and knowing it makes my work so much more intentional.

I’ve recently asked several internal stakeholders for feedback on a new product idea pitch, to build a first version of something that potentially has a high return, but also contains a lot of unknowns for us (in terms of business value). A classic bet.

As our team is using Shape Up to build products, the pitch mentioned a very specific appetite of 3 weeks, 2 developers and 1 UX designer.

Can you guess what happened?

Exactly.

And it reminded me just how much I love trade-offs. This will be fun!

Side note: I mean this with absolutely zero sarcasm. Problem-solving within constraints, making hard and deliberate decisions about what to do and what not to do, steering discussions and lobbying for understanding – I cannot image a more fulfilling role.

There was a time in late 2018 where we were having real trouble shipping the things we had planned to ship within the timeframe we’d estimated. I remember a particularly gnarly project where we wanted to enable our users to book multiple spaces within a given location – instead of being able to book just one space per location at a time. What we’d originally estimated to take roughly 3 sprints ended up taking around 5. Some people on the team will still shudder if you mention “multi-space bookings”.

For context: At store2be, we’re building a platform where brands and live marketing agencies can book promotion spaces in physical locations such as shopping malls, train stations, universities, airports, public spaces and more.

Since then, we’ve started to implement Shape Up – a product development framework developed at Basecamp and put into writing by Ryan Singer a few months ago. For the purpose of this post, I’ll assume familiarity with the framework. If this is your first time hearing of Shape up, you best get started by reading the book (online or PDF) or by listening to some of the podcasts linked here.

If you don’t know something today, you google it. That’s great for a lot of things, for example if one of your biggest concerns is settling dinner-table arguments around “Who played X in the movie Y again?” or “When exactly did Z happen?”. Googling has become such a knee-jerk reaction to any question for my generation (90s) and the ones after us – but it’s not always helpful.

When I entered the workforce at age 26, I joined a new company as one of their first full-time hires. It was four co-founders, me, a programmer and a few interns. None of us had any real work experience. So when you’re dealing with nuanced topics like Product Management, Strategy or Marketing, let me show you what a 26-year-old who’s just getting started in any of these roles, on a team with no experience to guide him, would learn by googling.

While working on an internal document on the progress that we’ve been making in moving towards continuous product discovery, I came across The Place of UX by Ryan Singer of Basecamp. A thing he wrote in the comments stood out to me in particular:

[W]hen we work on entirely new products … [it’s better to have] a small intensely collaborative pool who figures everything out together.

As I am currently working on a product that is more or less entirely new, this comment was immediately relevant to me. But initially, I took this comment as an advocacy for letting everybody on a small team working on a new product figure everything out. With the dual tracks of product discovery and product delivery on a product team now accepted knowledge, at least to my understanding, this sounded a lot like running a single-track team. But let’s back it up a bit.