Starting to think Product Management will be overtaken by Product Engineering.
Engineers are learning product. PMs aren’t learning how to build.
Reminds me of “information architects” in the old days arguing that nobody understood how important they were. Then they disappeared.
I'm starting to think the UX field is overdue for a good primer on how to really *do* interaction design.
Current education is way too focused on polished deliverables. Not enough on-your-feet skills and thinking techniques.
Interesting asymmetry.
When shaping, it's important to have one narrow problem and multiple paths to solving it.
Agreeing on the problem prevents us from getting frustrated. Finding multiple paths ensures we don't miss opportunities.
When projects take longer than expected, people usually think the problem was at the end of the project.
The problem is almost always at the start. The team didn't have a process for breaking apart the work, seeing how the pieces fit, and choosing what to do first.
Palantir's "Forward Deployed Engineer" role.
Good example of engineering taking more responsibility for problem definition and shaping. Opposite of ticket takers. Palantir's Ted Mabrey said "We think of the FDE model as one of our greatest secrets."
Async collaboration is essentially additive. It’s easy to add a comment, add an objection, add more code, add to the scope.
That works when implementing pieces of an agreed concept.
It doesn’t work when we need to change direction, remove something, or make trade-offs.
Looks like Figma's idea of improving designer-developer relations is helping designers dictate MORE decisions up front. They're even helping designers create Jira tasks from inside Figma!
Be suspicious when 8000 designers in a room clap for features made for developers to use.
FINISHED filming my new course "Shaping in Real Life." Comprehensive, detailed, REAL how-tos on every phase of product development: from framing problems, carving time, shaping, spiking, to hand-off and delivery. Even more content than Shape Up, and for a wider variety of teams.
A deep point about design that took me a while to appreciate:
Requirements are chosen, not “real.” The things we accept as requirements reflect our perspective on the problem.
Research and data are inputs to that. But making something into a requirement is an act of alignment.
Key difference between Miro and Lucid Spark. Miro is multi-scale. Here I'm zoomed all the way out to 2% and I can still add readable structure at high altitude.
Multi-scale UIs are rare. Other than Miro and Google Maps I don't know many examples.
Apple: "We present Ferret-UI, the first MLLM designed to execute precise referring and grounding tasks specific to UI screens, while adeptly interpreting and acting upon open-ended language instructions."
I've started saying "prototyping" more, instead of "iterating", after I learned something from
@bmoesta
.
Prototyping means trying wildly different options that cover more possibilities to discover what works.
Iterating implies gradual change down one path we're already on.
Two broad patterns that nearly every information system UI is missing today:
1. Let me draft the thing first, instead of "here are fields, now give your final answer."
2. Let me explore parallel options A, B, and C of the thing when I don't know the answer.
Examples...
New video! "Shaping in a Nutshell"
Now when someone asks "what is Shape Up?" you can just send them this.
Coming next: "Shaping in Real Life" — a course to solve the disconnect between product and engineering, w/ concrete how-tos on framing and shaping.
It's easier to move furniture than to move walls.
But today most software teams bundle all the design — walls, paint, and decor — into a single high-fidelity mockup at the start.
Better to get the rooms right first. Do the pieces connect? Do they create the value we expected?
Been thinking about learning Clojure for years. I saw is built in Clojure/ClojureScript and decided it's a good time to start.
Just did the first hour of
@jacekschae
's course at . Very refreshing and fast-paced experience.
At the start, writing isn't writing. It's figuring out what to say, where to begin, and how the dots will connect.
Same for UI. Somebody can say "sketch a concept for this feature." But at first, sketching isn't sketching. It's figuring out what the thing is supposed to do.
Design means answering:
What are the parts and
how do they connect
so that they fit the purpose.
When we're building and we discover we don't know what parts to include, that's a signal to flip back into design.
Feeling productive with Hotwire, Stimulus and vanilla JS on this Rails app. No heavy React stuff.
After a few days of hacking, it replaces the Miro board I've been using to scope and sequence development work.
Very good intro to
@remix_run
by
@samselikoff
. Love the format. Like a cooking show, he fast-forwards through the slow parts (you never watch him type) and shows the highlights, take-aways, decisions.
Agree to the Rails comparisons. Especially w/ Stacks.
Starting building an app in
@remix_run
(on the Blues stack).
Rails folks talk about "Javascript sprinkles" — using just a little when needed. Remix feels like "React sprinkles."
90% of the code is rendered server-side, and the React interactivity is great for specific UI bits.
My mental shortcut for thinking about Vision Pro: it’s like headphones, but for all computing. I think about all the times I use headphones instead of speakers (privacy, traveling, not annoying others, no speakers where I am, signaling “leave me alone”…) and they all map over.
Order of operations — the sequence we choose to solve design and build problems — is a huge progress multiplier. 10x more impactful than choice of framework.
As designers, it can be hard to feel secure and confident about our individual taste, style and judgement. What's "good" and what's "bad"? So we naturally look to our peers.
This can lead to clustering and in-group out-group distinctions. And, being human, some emotions get
I can see that 37Signals’ products look different from most other web applications. And I can see that they lean towards obviousness more than elegance sometimes. But I’ve never been able to see why people think it’s bad. Maybe I have a blind spot?
Lately I've talked a lot about building software like building a house: getting the walls, wires and pipes in place before the interior design details. Here's an example of what that looks like.
I'm building out a new website. Instead of starting pixel-perfect, I shaped a
The first order-of-operations hack to learn:
Instead of starting with a high-fidelity mockup, use the "parts on the floor" approach.
Figure out (1) the data you need, (2) the raw affordances for the UI (buttons, fields, links), then (3) wire them together with no styling.
Christopher Alexander passed away at age 85.
What a good example of what one can do with a life: making gifts to the world.
May his idealism and insistence that our lives be made meaningful through kind actions inspire many.
Documented every step of shaping this project, from analysis and problem definition all the way to writing a pattern language w/ example sketches.
Many thinking tools used along the way to wrangle the problem, plus some mocking and spiking to remove rabbit holes.
Improving a messy product is hard. The closer you look at the ugliness, the more you want to throw it all out and start over. But that's not always possible. We can't stop the world and redesign everything.
What helps us make meaningful progress is a watertight "frame" — a
LLMs make much more sense if we stop thinking of them as intelligence, and instead think of them as media. They are basically a new kind of media with very different storage and retrieval properties. The pattern matching is so rich that this medium can "store" behaviors.
Trying a new scoping exercise at kick-off. After shaping, before any UI/code.
Programmer: "I haven’t written any code, but my feelings have drastically changed about am I going to be able to deliver this well within the timeframe and am I gonna deliver everything that’s wanted."
A programmer on our team reflected on how we're working:
"What I've learned is... when something is unknown, the first thing to do is place restrictions on it so it doesn't take over the project."
"Constantly whittling scope makes it easier to understand the moment I'm in now."
Highly recommend Grokking Simplicity by
@ericnormand
. This bit in Chapter 8 reads like a fresh take on "Composed Method" from Kent Beck's classic Smalltalk Best Practice Patterns.
We don't only "do" work.
Sometimes we unpack work — figure out what's involved.
Sometimes we factor work — pull out things to do separate from the rest.
Sometimes we shape work — design an approach that fits our constraints.
Suspecting software architecture decisions like monolith vs. micro-services are less about code and more about management hopes. Hard interfaces imply — perhaps misleadingly — that teams will work in parallel, without collaborating.
The economics of interfaces are such that they
Just finished a small demand-side research project.
Interesting to view it as a series of rescaling operations, like the renormalization group in physics.
From ~6 hrs of interview data to 49 causal factors to 13 dimensions to 3 jobs to be done.
Someone looked over my shoulder and said "Visual Studio! So you're programming. What are you doing, front-end or back-end?"
This project is in
@remix_run
, so I said "both."
Put together a mini user guide for the alpha users of the Handoff tool I'm building.
It lets senior programmers do something they didn't think was possible: help junior engineers get better at breaking down work. Catches problems early in the cycle and prevents blowups later.
Learning to distrust workflows that look like this:
"Do the work > Review to see if it's what we wanted"
Need to flip it around:
"Define what we want > Do the work"
And, importantly, prepend this:
"Do the work of figuring out what we want > ..."
Gave a spontaneous short lecture yesterday on how to start in UI/UX design from absolute zero knowledge.
Started w/ patterns, then connected to real-world component systems (Swift UI, raw HTML, Tailwind, etc), then lego-building, then breadboarding.
It might become something.
I can't remember the last time I saw an enterprise software offering so far ahead of everyone else in its category. For 20 years the enterprise has been stale and innovation has come up from the bottom. With Foundry, the story looks very different.
Almost no software today lets you prototype — play with options for the same slot of data before deciding.
In a calendar, you can't capture trip plan A *and* alternate plan B and decide later.
In Keynote, duping a slide to try something while keeping the original.
Head of a design agency in Brooklyn just told me he makes every new design hire read this piece from 2012:
Why? So the designers learn to "clear one room at a time" instead of trying to solve everything at once.
"It's a focusing agent."
Working on some teaching material to help a wider variety of real-world teams implement Shape Up.
(Took inspiration from Kathy Sierra's work and replaced abstract iconography with more brain-tickling photos.)
A couple key ideas...
Important programming skill: stopping to question what we're doing.
When we're pecking at things, not making progress, ask: Do I know what I'm actually trying to do right now?
If no, step out of the code to shape an approach.
If yes, refactor so the next step becomes clearer.
13. Beyond to-dos
"When smart people tackle work, they do work *on* the work to figure out what the work is. They do it in their heads or on paper or on a whiteboard, not a to-do app. To-do apps are made to account for work, not figure out what it is."
Prototyping a super lightweight way to shape and track work. Here's a little one-week project I'm doing with a programmer. Using techniques from "13. Beyond to-dos."
Just saw the most brilliant app integration at a Moscow restaurant.
A QR code on the table lets you pay the bill and leave whenever you want.
Totally solves trying to flag the staff, waiting around for the check, splitting the bill, and tipping in one fell swoop.
My talk from
#RailsWorld
about "Shaping in the Real World" is online. The talk dispels some misunderstandings about what it means to shape, how it's done, and how to give teams more autonomy without taking unrealistic leaps of faith.
After 20 minutes of describing a task ... "so, when do you think you can get this done? By next week?"
Funny how we often put the question of time and capacity at the *end* of the ask. To make work actually happen and ship, the first requirement is capacity to do it.
a common comment/question: if you use hypermedia as your web application API, what about other clients?
good news, we've got some essays on that:
TLDR: your webapp & general API needs are different, so splitting them up is good!
"The new
@tldraw
is designed to be a primitive for infinite canvas applications."
Eager to follow this, alongside
@reactflowdev
. Tons of potential for innovative UI when 2D dragging of elements is no longer a development hurdle.
Just found this app in the Atlassian Marketplace for doing the delivery side of Shape Up in Jira.
If anyone tries it, I'd be interested to hear how it works.
Info here:
PMs often prioritize work by something called "impact." But usually what a PM considered "high impact" doesn't actually get the green light from leadership. Why?
One big piece of this problem is about the unit. What's a "unit" of impact? How do we weigh two projects against each
When it comes to product, "management" and "ownership" are popular terms.
What we don't hear as much is "execution."
Execution requires going further than saying what *should* be done. It means making trade-offs about what *can* be done under the constraints we have.
To do fixed time/variable scope, you need to be clear on what’s NOT variable.
Variable scope doesn’t mean “figure it out during execution.”
It means “here’s what’s truly important about the concept” and giving latitude for the rest.
Most of the “variation” happens in shaping.
By far my most important takeaway from studying
@bmoesta
’s Demand-Side Sales 101 was learning to tell the difference between when I should describe a solution (active looking) vs. when I should tell a story about how someone else solved the problem (passive looking).
Shaping isn't writing. It's not filling out a template or creating a document. It's getting to that "a-ha" moment together where the parts and their connections crystalize and we have something that will work.
I'm fascinated by this image from Mark Spitznagel's "Safe Haven".
You hear about exponential growth all the time. His focus is on "logarithmic cost".
When we take losses in a growth process, we fall down a curve that requires exponential gains to climb up again.
I've been using Miro for almost every step of the shaping process lately. It's fast (few clicks) and the defaults are usually what I want. I can copy/paste work at each step into future steps to make a long chain of history, showing how I got to where I got.
I'm writing a post on how to use a chain of tiny tools to incrementally shape a project.
I wasn't sure how to start. The post felt big and complicated. Too many things to say.
So what did I do? Shaped it incrementally with a chain of tiny tools... 🌀
Knowing the end state someone should be in and knowing the specific steps they should take next are two very different things.
Applies to teaching, advising, UX. Moving forward requires taking steps. Designing those steps requires understanding where the person stands right now.
In product development for manufacturing, gross margin is one of the important constraints up front. In software, we aren’t used to thinking about margin because the marginal cost of duplication is effectively zero. But that doesn’t mean we don’t have production costs!
While we
Made a lot of progress unpacking UX over the last year into different layers that need attention at different times.
The first separation is between the architecture and the interior design, just like in a house.
Consider a bathroom. The decision about where to place it is very
Best programming book I’ve read in a long time:
“Getting Clojure: Build Your Functional Skills One Idea at a Time” by Russ Olsen
Makes functional ideas seem natural and simple. Very little theory, lots of real-world how-to. Well paced and sequenced.
I still believe this Theory of Twitter to be true:
Twitter is where you go to say things that no one in your actual vicinity wants to hear.
Explains both the terribleness and awesome niche-ness.
⭐️Thrilled to announce I'm now accepting applications for the first group of early-adopters for my new, intensive video course:
SHAPING IN REAL LIFE
Full outline of the course, dates and details here:
Lately I haven't been "writing" my project pitches. I'm starting to think that freeform prose takes more effort than it's worth.
Now I'm dragging & dropping statements together, inspired by Christopher Alexander's per-project pattern languages. Way faster.
Custom tool + output:
Instead of starting with hi-fi designs, I prefer to start by laying the parts on the floor and wiring them up.
First, get affordances on the page, wired to code, in an ugly way. Verify that it works and is useful. Then rearrange, style, and finish.
Example from a WIP project.
Working on a new app, with no MVC framework. Started to feel tangled. I couldn't see the tangles well enough from inside the code, so I zoomed out and refactored it visually. Better topology, better design.
I'm surprised how often I've heard the story:
"We weren't shipping. We fired the CTO. Now I'm in charge of strategy. We need to focus on shipping stuff that's valuable. I've tried setting appetites, but the team just keeps expanding the scope."
How to narrow down the scope?
Feeling grateful for 2021. Worked with a wider variety of companies. Learned a ton about how to improve collaboration across the shaping and build phases.
Plus: Built an alpha product, in use by some early-adopter teams. Wouldn't be possible without this network here. Thank you.
Sometimes I know what I need to do, but I don't know where to start. In those cases, I reach for the interrelationship diagram.
1. Dump everything
2. Figure out which things enable me do which other things
3. Foliate to see the sequence
When you work this way, you start to see product design in two phases, like building a house.
First you work out the big load-bearing elements. Then *later*, after it stands, you do the interior design — the paint, decorations, exact furniture placement.
The first order-of-operations hack to learn:
Instead of starting with a high-fidelity mockup, use the "parts on the floor" approach.
Figure out (1) the data you need, (2) the raw affordances for the UI (buttons, fields, links), then (3) wire them together with no styling.
Disconnects between product and engineering are frustrating. Designers' work gets thrown out, and technical people don't have the requirements they need to be productive.
Weird thing. I never use Excalidraw when working alone.
But if I have to communicate with other people, I always find myself going back to it. Especially to make breadboards.
⭐️ 20. Framing.
A new step before shaping. Why pitches sometimes look like "sales pitches" to work on something, without rigorous shaping. How to align with the business before shaping to carve out time to properly shape.
Seeing a pattern with teams who shape well.
They factor both the appetite *and* the build team into the shaping. They shape *to* a particular team — what the team knows and doesn’t know, their experience and capabilities.
Soundboarding w/ builders during shaping tests that fit.
Simple naming convention for to-dos.
I was just saw this again at
@Autobooks_
. They picked up the ~ thing from Shape Up. Then, funnily, found it natural to put the ? at the beginning of tasks that need investigation. I had started doing the same thing a while ago too.
This is what the end of a shaping session looks like. Three people were on a call for two hours.
Note how messy it is. You had to be there to understand what it means.
Next step is "packaging" this into a doc that readably captures what we learned, to carry forward to delivery.
For fixed time/variable scope to work, what varies has to be bounded. There has to be an outer wall defining what it is and what it's not.
Variable on the inside ("there are different ways to do X") is different from variable on the outside ("is X the right thing to be doing?").
Must-watch talk by
@ryanflorence
. Gives the “a-ha” moment for seeing React Server Components as a simplification. The analogy to border-radius in CSS is so good.
So wonderfully inspiring. A student project following Christopher Alexander’s method. Notice how so much of the design came by studying the site: what worked and didn’t work in that specific context. Really beautiful.
What sounds like a problem often isn't concrete enough to actually design against.
Common one: "____ takes too much time."
Need to dig deeper and ask: So what? When, in what chain of events, does it become a problem that X takes so much time?