I spend a lot of time coaching and training teams in agile methods, design methods, and product discovery. By the time we’ve finished a training, I’m pretty confident that folks khow how to use a certain method. But that’s not the same as knowing why to use it. In fact, the main reason that I’m effective as a coach (as opposed to as a trainer) is that I know both the what and the why.

Let me give you an example. 

My daughter called me earlier tonight, in the middle of cooking dinner, to ask about making spaghetti carbonara. Never mind that she was half-way through cooking it. That’s how she is, she’ll start cooking without really having an idea of the whole process. “When the pasta is done, I’m going to make the egg mixture,” she said. “Can you remind me what goes in that?”

If you know pasta carbonara, (and you should), you know that it’s a magic dish. Cured pork (guanciale or pancetta), eggs, cheese, pepper, and pasta. When it comes together, it’s… well, I already said magic, but it’s magic.

There’s exactly one critical step in the process. After you cook the pork, after you mix the eggs and cheese together, after the pasta is done, you turn the hot pasta in the egg mixture. The heat from the pasta cooks the egg. This is the only non-negotiable part of the method. It’s the organizing why of the whole thing. Hot pasta cooks the eggs…and magic. Cold pasta leads to failure and… whatever the opposite of magic is.

So when my daughter called to tell me that she’d attend to the eggs once the pasta was cooked, you can imagine that I cringed. NO! (I didn’t shout, I just wanted to.) You have to make the egg mixture RIGHT NOW (again, I didn’t shout) so that it’s ready the moment that the pasta is done.

Nonplussed, she said, “OK,” got the information about the egg mixture that she needed from me, and hung up. 

---

This is the difference between knowing what and knowing why. I see this so often in the teams that I teach. Teams will learn to interview customers, but they lose sight of why they’re doing it. When you do that, you’re just checking a process box. Or teams will write OKRs, but they lose sight of why they’re doing OKRs. What’s the opposite of magic? Doing OKRs without knowing why.

So what do we do about this? Well, this is why experience matters. If you’ve never used a method, and if there’s no one on your team with this experience, then you’re at risk. This is part of the value of coaching.

In coming weeks, I’ll write more about coaching. But until then, think about the places where you know the whats, and then think about the places where you know the whys. They feel different, right? 

Maybe you’re wondering how that pasta my daughter was making came out? Thirty minutes after the first call, she texted me: “Came out perfectly delicious!”

I got my first job at a design agency in 1996. We designed software products for technology companies. There weren’t many companies back then (pre-web) who did this work, and it was unusual for tech companies to hire design companies to work on their software. As a result, we needed to spend a lot of energy to justify the work that we were doing. One of the ways that we did that was by extolling our rigor. A typical project for us included a month of field research, followed by 2-4 weeks of wire-framing, followed by 4-12 weeks of detailed design. In other words, by the time we were done and ready to hand off our work, we’d spent months working on the blueprints that we handed off to developers.We were proud of how much work we did to get things right.

Around this time, I first saw an article about agile methods, specifically, a piece about Extreme Programming. What a name! In the studio, we mocked the whole idea endlessly, not least because the number one bogeyman of extreme programming was Big Design Up Front. They called it BDUF! How ridiculous to think that was the enemy! That was our entire existence!

And there you have it, in its infancy: the outline of an unavoidable and perpetual debate in the software world: how much work do you do before you start writing software? In the studio, we argued that you needed to build a rigorous plan. In the XP world, the argument was that software requires discovery, so you should start discovery immediately, and that the best discovery was actually writing software.

Of course, in most polarizing debates, there’s usually an element of truth on both sides.

Fast forward twenty years, and I’m having coffee with Lane Goldstone, one of my former studio-mates. Both of us have spent years since those studio days working to combine design-centric and agile ways of working. Lane, reasonable and thoughtful as always, said to me, “You know, we were right that the up-front work is important. But we were wrong about how much we needed. It turns out that you can get away with less than we thought. Much less.”

Getting Away With Less Than We Thought

I was thinking about this because last week I was teaching a unit on strategy to a group of Product Managers. With my colleague Jeff Gothelf, we focus the lesson on two questions, described in Roger Martin’s article The Big Lie of Strategic Planning. In the article, Martin says that the two critical questions that strategy must answer are, “Where will we play?” and, “How will we win?” 

Let me give you an example of these questions in action. Before I worked in the design studio, I worked at a company called Kensington. In those days, Kensington was a 40-person computer accessories company. When I joined the company in 1990, our strategy was simple. Where did we play? We made accessories for personal computers, and we sold those accessories through US retail channels. How did we win? We made a limited number of accessories, only entering categories where our product could be the best in the market, and for which we could charge a premium price. Our flagship product was a trackball—the best and most expensive on the market.

While I was working there though, something changed. The US market saw the rise of the big-box store. WalMart. Sam’s Club. These stores didn’t want to do business with lots of small suppliers. They wanted to deal with companies that could supply whole categories of products. They didn’t want our trackball. They didn’t care that it was the best in the world. They wanted to work with a supplier who could fill their mouse aisle. That meant supplying a $2.99 mouse, a $5.99 mouse, a $15.99 mouse, all the way up to our $99 trackball. 

In other words, there was a new player in our market, and if we wanted to stay competitive in this market, our strategy would have to change.

We could have re-thought our market, but the opportunity was too big to walk away. So our where-will-you-play didn’t actually change: we still made accessories for personal computers, and we still sold them in US retail channels.

But we had to change our how-will-you-win. It became: we make the best product at every price point in the categories that we enter.

Now, this may not seem obviously useful to you, but let me assure you that strategy, framed this way, is tremendously practical. It serves the kind of decisions you have to make in your day to day work. For example:

Should we launch this new product? 
Well, can it be the best at it’s price point?

Do we need another product in our line? 
Well, are we missing a price point? 

Should we change suppliers for this part? 
Well, will it make the product better without increasing the selling proice?

Strategy, like so much of what we do in business, can be inflated in order to justify the work. But at it’s essence, it’s simply a way of describing your approach to problem-solving. As I teach it, it’s a guiding policy to solve a problem. Where will you play / how will you win is useful because it can be the smallest thing that you need to articulate that policy. And it’s simple enough to use it moment-by-moment to make decisions. 

Thinking about strategy this way is, for most people, a revelation. It takes strategy—the elevated endeavor pursued by highly-paid consultants—and puts it back where it belongs. It’s just a guideline to for your decision-making process—and one that is applicable to you in your day to day work. 

In other words, you need it. You just need less of it than you think.

In January, as the new year is starting, people often make a resolution to write more, so I thought this was a good moment to re-post this piece from a few years ago.

The piece is about dealing with writer's block. In college, I struggled with writer's block. It was bad. Really bad. It very nearly killed my college career. But I was able to find a solution, and that solution continues to work--in fact, I use it to this day, and I used it while writing all three of the books that I've published.

This piece is from 2014. I was working then with a group of colleagues who wanted to get better at blogging. We were about to start an after-work blogging club, and I wanted to share some of what I knew about writing with them. I dashed this off, and (as often happens when you dash something off), it became one of the most popular things I've ever written.

So I'm sharing it here with you. I hope you'll find it useful.

The first thing to know is that many people confuse the act of writing with a different activity, one that is actually a mish-mash of three very different things: research, writing, and editing. If you have trouble writing, it may be because you’re trying to do all three things at the same time. You can’t. Give that up. Instead, do only one at a time.

Because this note is called HOW TO WRITE, I won’t talk about research, and I will say very little about editing. I am only going to tell you HOW TO WRITE. So, forthwith…

WHAT YOU NEED

You will need some EQUIPMENT.

You will need to know THE PROCESS.

You will need to know THE RULE.

Then you will need to START.

THE EQUIPMENT

You will need a 20-minute timer and writing implements. The implements can be a word processor, a pen and paper, whatever.

Pro tip: equipment to avoid: an internet connection.

THE PROCESS

When you have secured your equipment, use this process.

1. Find a place where you can sit without interruption for 20 minutes.

2. Set your timer for 20 minutes.

3. Start writing. Do not stop writing until the timer is done.

That’s all there is to it.

THE RULE

Perhaps you didn’t notice, but I did something sneaky up there when I shared THE PROCESS. I snuck in THE RULE. THE RULE, in case you missed it, is this: DO NOT STOP WRITING UNTIL THE TIMER IS DONE. This may seem hard at first. You may run out of things to say. You may not know how to start. But these are not actually problems. Just write, “I have nothing to say.” Write that over and over until you get so bored with yourself that you are motivated to write something else. Then perhaps you will write, “I don’t know what to write about.” Write that for a while. Then maybe you will find yourself answering yourself with something like, “You said you were going to write a blog post about why we are now in a Post-Lean Startup Universe.” And then, “Let me tell you why we are now in a Post-Lean Startup Universe.”

If you can see where this is headed, great. If not, let me spell it out for you: as long as your hands are moving, your brain will eventually start to engage with a topic, and before you know it you will have filled pages and pages and pages with words.

When I say, “DO NOT STOP WRITING UNTIL THE TIMER IS DONE,” I mean it. Do not go back and correct your work—don’t even fix typos. (That’s editing. It’s not writing.) Do not go searching the internet for that quote you want to use. (That’s research, not writing.) You are just going to have to write something like, “And then Albert Einstein said to what’s-his-name that thing he said that I wanted to quote but will look up later.” And you keep going. Because you’re writing now. You’ll do your research and editing later.

THE IMPLIED COROLLARY TO THE RULE

I didn’t tell you I would include this, but it’s important so I’m going to throw this in for free: if you follow THE RULE, then you will write successfully. To write successfully is to put words on a page or into a text file. Writing successfully is not the same thing as writing well. To write well, you have to go back and do that other thing: editing.

THE ONLY THING I’LL SAY ABOUT EDITING

I said I wouldn’t say much about editing, but I will say this one thing: when you are editing, you are a deadly samurai warrior. You slash writing to bits until only the good and pure and worthy words are left. But when you are writing, you are not a samurai. You are a waterfall or some shit and your job is just to let those words flow and flow even if the good ones are all tumbled up and white-watered with the ones that are rotten and filthy and polluted. Just remember that you can’t write and edit at the same time. Why? Because you can’t be a samurai and a waterfall at the same time because that shit makes no sense at all. First write. Then edit. Then repeat.

IN SUMMARY, HERE’S HOW TO WRITE

1. Find a place where you can sit without interruption for 20 minutes.

2. Set your timer for 20 minutes.

3. Start writing. Do not stop writing until the timer is done.

NOW, START.

* Post-script to acknowledge my teachers: I first learned about these ideas from Suzanne McConnell, who was my first writing professor at Hunter College. The timed writing exercises in her class were a revelation to me. She will not remember my work, but her class turned the course of my life around. I think it was for that class that I was first read Natalie Goldberg’s “Writing Down The Bones” which describes this method in detail. I have shamelessly stolen the image of editor-as-samurai from her. I owe both women many thanks.

In early 2019, I published a little book called Outcomes Over Output. To say that this book has exceeded my expectations would be an understatement. It’s sold tens of thousands of copies, and it has connected me with readers from around the world.

One reader wrote recently to ask if I could share a discussion guide for Book Clubs that wanted to read the book together.

So, here is the discussion guide for the book. I hope it proves useful. If it does (or if it doesn’t!) get in touch and let me know how the conversation went.

Outcomes Over Output, by Joshua Seiden

When I started my career, I worked at a computer accessories company named Kensington. We made some really great products, and I was lucky to work on those as a young product manager. But I also worked on some real dogs. Stinkers. Bad ideas that should never have made it beyond the brainstorming meeting. I spent nearly a year of my life on one of those. It made me start to wonder, what was the difference between the great products and the stinkers? And how could I spend more time on the great stuff, and less time on the stinkers?

For a while, I thought design would be the key. After Kensington, I got a job working for the wonderful Alan Cooper, working as a designer in his studio in the late 90’s. Alan was a passionate advocate for the idea that design was critical for software. He believed that you couldn’t make great software—great tech products—without design. I was thrilled with this idea. Finally, I understood where the stinkers came from—it was a lack of design! (Stay tuned, reader: I was wrong.)

The idea of design in software was, amazingly, a radical idea in the 90’s. Most people didn’t think design had any business in the software world. I heard one IBM executive—a person who ran their mini-computer division at the time—tell Alan that he was wrong. Software design, she said, was the responsibility of engineers. 

But then the internet exploded, and with it came “web design.” Suddenly, designers were everywhere, and now 25 years later, we’ve come to accept that design is important for making great tech products. But the tech world and tech leaders still don’t really understand what designers do or how to get the best results from design. Part of my goal in starting this newsletter is to share ideas and techniques to help teams get the best results from design.

That thing you do… is it Design, or is it Product Management?

Starting in about 2011, I started leading workshops in design methods for product teams. People loved the training, but I was surprised by a common theme in the feedback. People said things like, “I wish my product manager was here for this.” Or “This isn’t a design training, it’s a product management training.” 

The more I dug into this feedback, the more I realized how accurate and important this feedback was. The methods that I’m interested in are methods that are important for both designers and Product Managers. These methods are about understanding customers and users. They are about framing problems quickly and accurately. They are about testing ideas quickly, cheaply, and safely, and they are about creating great products. You can call this design or you can call this Product Management. You’ll be right in either case.

So What Will Save Us From Terrible Products?

Remember I said I was wrong: design wasn’t going to prevent stinkers? Well, sadly, neither will product management. It turns out that there’s no one thing that can save us from terrible products. Design is important, maybe even critical, but it’s not enough. Product Management is important, but it’s not enough. Data, QA, writing, engineering, none of it is enough by itself. 

So what’s going to “save” us from terrible products? Well, I’ve come to believe that it’s about really well-rounded, cross-functional teams, collaborating effectively on well-framed problems. And that, as much as it sounds like mom-and-apple-pie, is really hard to achieve. And that, finally, is what this newsletter is about. How to be better at working on cross-functional teams, mostly for designers and product managers, but also for everyone who does this work, and who has a stake in the outcome. 

Hi and welcome to the newsletter. I’m glad you’re here. 

I work with product teams, helping them understand design, product management, strategy, and agility. I do some writing too: you may have read my books, Lean UX, Sense & Respond, and Outcomes Over Output.

I’ve decided to write this newsletter for you, the designer, the product manager, the member of a product team, or the person who works with product teams. Maybe you’re a data scientist. Maybe you’re a QA person, or a marketing person, or… My goal here is to help you work more effectively with your teams and colleagues to make great stuff. I’ll do that by sharing what I’ve learned in my 32 years (OMG!!!) in the business. I’m a big fan of practical methods and straightforward language, and I hope you’ll find lots of that here. 

Why Now?

It’s 2023, and we’ve learned some things about digital product development–but what we know is not even distributed inside organizations, nor is it all widely practiced. We’ve also learned a ton about what NOT to do. I’ll be sharing these with you here. 

In coming weeks, I’ll be writing about how to get aligned to a user-centric strategy, how to be more outcome-focused, how to avoid getting burned out by agile, how, instead, to make steady incremental progress week-by-week, how to practice continuous discovery, how to make OKRs your friend, and much more.

So, if that sounds interesting to you, stick around—or subscribe, or share with a friend.

Thanks,
Josh