Every few years somebody comes along with the answer – a new tool, a new framework, a new way of working.
The pitch is always the same: “use this, and your life will be better!”
But it’s just not true.
As someone who has spent a big part of his career working on Jobs, over the years, I’ve heard consultants say, “If you use Jobs to be Done, you don’t need anything else.”
I shudder when I hear that. I’ve never seen one tool that does everything for you.
Jobs tells you the what – the progress people are trying to make. It doesn’t tell you the who. There could be five personas who all have that same Job, and knowing which ones you’re going after helps you design the product within that Job.
Jobs is a great tool, but it’s just not the only one you need.
The screwdriver problem
Here’s another way to think about this.
Can you use a screwdriver as a hammer? Sure. If I don’t have a hammer and I really need to get something done, I can whack it in there. But it’s not designed for that, and it’s not its best use.
In an emergency, it might work. But it’s not ideal.
Think about your business – why would you put your roadmap, your portfolio, and your biggest bets on one tool?
If you’re the one accountable for what gets built, why wouldn’t you use the tool that works best for what you’re trying to solve? And why would you hedge your bets on just one way of thinking?
You wouldn’t but it’s often what happens because we don’t spend enough time discussing what the problem is in the first place.
Don’t dive in – unpack it.
Most of us got to our senior-level roles by being good problem solvers.
Something isn’t working, so you tackle it. You dive in. The trouble with this, however, is that when you dive into a problem without understanding the system around it, you usually create other problems.
We see this all the time with the teams that come to us.
A product isn’t quite working, so the team says, “Well, we’re going to change A.”
But when you change A, you’re changing a bunch of things, because you’re changing how A interacts with everything else. Now something else is off, so you say, “If we change C, that’ll make A better.” You change C, and it still doesn’t work right.
That’s one factor at a time. It destroys timelines, it changes decisions mid-project. And what’s worse, when you create a new problem, you don’t know how to fix it, because you never learned how the system works.
So when a problem gets identified, take a step back.
Ask what this thing is supposed to be doing. Ask what’s going on that we think isn’t right, and what all the pieces are. For example, let’s say you work in CPG. If you’re trying to fix flavor, it’s not just the flavor. It might be the preservatives, or the temperature you cook it at.
Change one thing and you might change three others. Then you can design how the pieces interact, so you know how far you can push each one without breaking something else.
(Still think using just one tool is the best way?)
In Jobs we talk about shaping the light bulb. When consumers don’t shape the light bulb, whatever they buy doesn’t quite work.
Product teams do the same thing. If you don’t shape the whole thing, it’s lopsided. The picture isn’t complete, so you can’t do what you need to do to develop it.
It doesn’t die with the project
Here’s the part I think gets missed the most.
Product development gets expensive because every project is treated as unique. We redo all the learnings every single time. But certain things stay consistent, Jobs stay consistent, and personas for a company generally stay consistent.
You don’t have to reinvent the wheel every time.
When we do a Jobs project, I want product leaders to realize it’s going to feed other tools.
What you learn about the Job feeds who you go after, and that feeds what you build. When you do the work with that holistic view, it doesn’t die with the project.
There are times you do have to go deep again. If you’re bringing a product to life in a new form, or a new-to-you form, the learning is going to be more intense. But that should be a choice you make because you understand the system, not because your team starts from zero by default.
The easy way out
People are looking for the easy way out more times than not.
Everybody throws around the buzzwords: be creative, be curious. But with all these specialized tools and consultants at your disposal, we’re actually driving the curiosity out of it.
Teams just want the answer; they’re not interested in how they got it, or in the struggle people went through. It becomes notes on a sheet instead of pain in people’s voices.
We need to get back to basics. We need to understand the problem before you solve it. Build a system of tools that work together, where what you learn in one feeds the next.
That’s the work we do at The Re-Wired Group. It’s not about one tool – it’s about using the right tools at the right time, building on each other.
If your team is starting from zero on every project, or you’re watching decisions change mid-stream, why not get in touch. Let’s talk about how your system works.