@okdan I'm sure all of this will become obsolete once we get some better tooling ... but I need our source of truth to be Claudable so I'm willing to put up with the churn :)
English
Ryan Singer
1.2K posts
Ryan Singer
@rjs
Hands-on product leader. Creator of Shape Up. Prev: Basecamp/37signals. [email protected]
Global Katılım Kasım 2007
17 Takip Edilen51.3K Takipçiler
At the moment, I have a directory per team (client, in my case). Inside that directory, there is a "private" directory where I store all my personal notes, transcripts, etc. And then a "shared" directory where I organize by project.
I only put things into the shared directory that have been digested/processed so that they are a meaningful source of truth.
The pattern so far is each project dir has a couple "evergreen" files that represent the current state, and then a chronological list of markdown files that represent updates about what happened, decisions made, etc.
English
Starting using a shared memory git repo with team members who are Clauded. Now when I want to explain something to them, I am oddly inclined to give them a prompt. "Ask this." Interesting tooling gap.
English
My friends at @seasonedcc and I just transitioned a sass app we built for managing vertical slices to a file-based CLI and localhost web app. Huge upgrade on many fronts. So excited to see where this goes.
English
Books are mirrors. Whatever we find fascinating or infuriating, exciting or uninteresting, is what they activate in us.
English
This new series from @chriscbs is gold. It’s the missing guide for the demand side of product strategy and describes what good problem/outcome framing looks like.
Chris Spiek@chriscbs
English
Added two new skills to the shaping skills repo. For taking transcripts from work sessions and turning them into framing docs or kickoff (shaping) docs.
These are HIGHLY GIGO. Totally depend on whether you did the work well and communicated it well on the transcribed calls. They're just shortcuts for capturing and synthesizing what happened and getting to the first draft of a source of truth.
English
Architecture is large scale structure that enables, bottom-up, by creating niches, and constrains, top-down, by creating boundaries.
The boundaries are the narrowing of the degrees of freedom, so the system does this better than that. The niches are the possibilities within those degrees of freedom.
English
Every project I've worked on, whether it's a 2 week fix or a 1 year integration effort, has that moment where I can see it on a napkin.
Not as the first step. Usually after hard work. Then all of a sudden OH. It's *this*, *this*, and *this*.
Architecture got a bad name from 90s software culture. But the ability to see the macro shape of a system is critical.
Where "architecture" goes wrong is in two areas:
1. Too horizontal. If the architecture describes an abstract platform that in principle can do anything you want in the future, that's a recipe for disaster. It means nobody made trade-offs and the system has no boundary conditions. A general house-building framework is not a house you can move into.
Good architecture has vertical stakes. "This is here because it lets us do X. For that to work, we also need Y over here. We know Y is working when we can demo A B C."
2. Too much detail at large scale. Blueprints and architecture aren't the same thing. You need a blueprint for permits and for contractors to work. But a blueprint is not an idea. It's not a system of trade-offs. It's not a model of how you solve the solution. The napkin is a SIMPLE picture that captures the essential relationships that solve the problem.
As a rule of thumb, always apply the "scale transformation." At large scale, there should be fewer elements across the whole system. At small scale, there should be vastly more. The picture should get SIMPLER as you move up. That means you have something you can point to, align on, make decisions around, set expectations and time frames around, etc. Any architecture with a 1000 wires in it won't be actionable in a decision-making situation.
English
Amazing how the web APIs keep getting better. 👏🙏
Ryan Florence@ryanflorence
They gave me everything I wanted in the new Navigation API. Grateful for folks like @domenic (and anybody else who worked on this) who make the web better. Just wanted to show off a few things as I took it for a spin for the first time in earnest.
English
Example: We don't like this button on row in a list.
If I have full context of why that button exists, I might immediately say "Oh it's not clear 'Edit' means and it's floating off to the side. This is about the assignment. Call it "Change" and move it next to the "Calendar assignment" block so it's clear what it modifies."
If I don't know why that's there, then I have to zoom out. Zooming out can be in time or in space.
Zoom out in time means thinking before/ after on individual workflow paths. What brought me here? What am I trying to do? What do I need to recognize to make the next step?
Zooming out in space means looking at adjacent elements on the 2D surface to see if there is sufficient contrast, grouping, separation, etc. Eg, where does my eye go first? Is it clear that these three things all operate on this and not that? Are all these "edit" actions actually symmetrical and so deserve the same verb? Are all these actions equally relevant on first load, and should some of them be styled secondary instead of primary to raise the signal/noise?
Those are examples at the level of the individual screen or interaction, when we assume the elements themselves are correct. I think of that like rearranging the furniture in a room.
The next level up is rethinking the walls of the rooms. Am I even seeing the right things here? Do I need to make a different "place" (screen, workflow step...) to put the right information and actions together so that we can make this workflow clearer / faster / more robust / etc.
A further level up is: which problems/outcomes are we actually trying to solve/achieve in this time frame (eg < 6 weeks)? Is this thing we are talking about even in scope relative to the business outcome that we are aligned on that makes us want to spend time on this right now? Where are the "walls" between this problem and the next problem? Or this thing we want to demo vs the next thing we want to demo? Etc.
English
This is about having an altitude knob. At the largest scale, context is clear, details are fuzzy, At the small scale, details are crisp, the context is fuzzy. A key product skill is knowing which scale you're at now and consciously shifting up/down for what you have to do next.
Geoffrey Litt@geoffreylitt
My favorite designers can instantly switch from loose / hazy / intuitive thinking to sharp / analytical / precise thinking on demand. Many people can do one or the other. The combination is rare!
English