Deleted tweets by Ryan Singer

rjs-deleted.md

Deleted tweets for rjs

The list below includes 3098 deleted tweets by rjs.

There are also 2 tweets that are indicated as not currently deleted by the Twitter API that have been scraped from pages of deleted tweets (as replies, etc.). These possibly undeleted tweets are included for context and are indicated by a (live) link.

This report was generated by ✨cancel-culture✨, an open source project by Travis Brown.

You can create your own updated version of this document by checking out and configuring the repository and then running the following commands:

$ cargo build --release
$ target/release/twcc deleted-tweets --report rjs

Please note that all tweets quoted here are sourced from the Wayback Machine and were not directly accessed through the Twitter API or any Twitter client.

• 26 April 2021: If you’re interested you can find a reference to @yaneerbaryam ’s work on scale tradeoffs here: https://synthetic.transistor.fm/episodes/scale-tradeoffs-in-communication-and-design
• 26 April 2021 (live): I reviewed your question and now I see the trade-off. IMO you can’t have something good past a certain scale threshold because scale requires oversimplifying (see Yaneer Bar-Yam’s work). Suggests looking into decentralizing and enabling bottom up actors to find an alternative.
• 26 April 2021 (live): It’s a false trade-off. See Christopher Alexander’s Mexicali project for a counter example of how to do very cheap housing.
• 20 April 2021: #12 Understand business imperatives to get the green light We have an important customer problem — why won’t the business give it time? https://world.hey.com/rjs/12-understanding-business-imperatives-to-get-the-green-light-0b610f00
• 13 April 2021: #11 Research gives us the problem, not the answer People often ask about doing research inside a cycle. Inside the cycle is too late. Research — when necessary — is for problem definition, and problem definition belongs in the shaping phase. https://world.hey.com/rjs/11-research-gives-us-the-problem-not-the-answer-d8a2303e
• 24 February 2021: FYI I have learned that integrating design + dev is important for us at Basecamp but isn’t strictly necessary for doing Shape Up. Article coming in my newsletter.
• 23 February 2021: I'm doing a Q&A about Shape Up on Clubhouse today at 11am Central. Hosted by Katie Runyan, a director of product who attended one of the early Shape Up Workshops. https://www.joinclubhouse.com/event/mJn6Dp3n
• 17 February 2021: Not about money. 1. Not all airlines fly all days/times in Mexico. When timing matters, options can shrink. 2. The refund isn't about money. It's about not being cheated. 3. Purpose of tweeting was to get them to act. It worked.
• 17 February 2021: After two hours explaining that we need a refund, and a call from you confirming that our refund is being processed ... I finally got an email with ... a voucher for future travel! Not a refund. Unbelievable.
• 17 February 2021: You told me on the phone my refund was being processed. Now I have an email from you with vouchers for future travel on Volaris — not a refund!
• 16 February 2021: I spoke to your staff, including a supervisor, who said they have "different directions" than your own published policy. Here are the terms+conditions linked on your own site. The terms say refund of 125% https://cms.volaris.com/globalassets/pdfs/eng/passenger-domestic-air-transportation-services-agreement.pdf Supervisor on the phone said "not our policy." pic.twitter.com/NmVQhv3IVN
• 16 February 2021: FYI: Never fly @flyvolaris . They are crooks. Canceled my flight. Gave no reason. Policy on their website says they give refunds. Supervisor at call center says they have "different directions" they must follow. Shamelessly criminal.
• 5 February 2021: See you there in 30 mins. We’ll be taking questions. https://twitter.com/rjs/status/1357406014639849474?s=20
• 4 February 2021: I’ll be on Clubhouse with @bmoesta and Greg Engle tomorrow (Friday) at 2:30pm Central. Talking about building product, shaping work, and jobs-to-be-done. https://www.joinclubhouse.com/event/M8XNKwb8
• 14 December 2020: Yeah, past newsletters are linked on http://Feltpresence.com
• 13 December 2020: Newsletter #4 is out. • Testing a new pitch format for shaped work • Measuring usage with a Taguchi signal/noise ratio Plus: • News on Ergodicity Economics pic.twitter.com/Y8cHq4FkSa
• 30 November 2020: @amyjokim @bmoesta These three videos are amazingly well done.
• 29 November 2020: Newsletter #3 goes out today. • Shaping with pattern languages Plus: • How Loupe does Shape Up with their clients pic.twitter.com/4XD0VNo80T
• 19 November 2020: Helps to unpack "planning" into distinct activities. The decision to allocate 4 cycles to BC4 next year was an ad hoc, punctuated thing. Not part of any process. The larger strategic arc of shaping BC4 tentpoles the demand-side is something I've worked on over the last year+.
• 19 November 2020: Response to my email newsletter has been amazing. 2,927 subscribers and growing. Many good 1:1 conversations. Thank you all. To finish the move off of Twitter, I'm going to stop linking to web versions of the newsletters. Details and signup form here: https://mailchi.mp/hey/ryans-newsletter
• 19 November 2020: Yeah for example, we expect to dedicate four cycles next year to BC4. But Jason and David will still decide on the actual moves cycle by cycle.
• 17 November 2020: Yeah. Think of demand shaping like site selection ... outlining an area to work within. Then supply side is construction. Many construction efforts can happen on the same site over time.
• 17 November 2020: Newsletter #2 is out. • Shaping on the demand side Plus: • Sequence != priority → https://mailchi.mp/feltpresence/newsletter-2 pic.twitter.com/HhdF0qwVtq
• 15 November 2020: Newsletter #2 is out. • Shaping on the demand side Plus: • Sequence != priority → https://mailchi.mp/feltpresence/newsletter-2 pic.twitter.com/XlEyik9BYO
• 13 November 2020: Ah. Applying to product design, not marketing. I see. No good public resources. I'll DM you. Key points unpack from this: the job tells you what experiences they need to have. From those come functional requirements for what it does. Those then tell you what to integrate.
• 13 November 2020: Check out the book Demand-Side Sales 101 by Bob Moesta.
• 12 November 2020: Awesome to hear. Thanks.
• 11 November 2020: No. https://twitter.com/rjs/status/1326630125341962242
• 11 November 2020: There are plenty of product managers who don’t have any problem with shipping, so then there’s no need to change what they are doing. But if they are struggling the way the quote describes, the book might help.
• 11 November 2020: Because it’s useful for some people. Some != all.
• 11 November 2020: My book gives the full context. Chapter 2 is short and probably most relevant: https://basecamp.com/shapeup/1.1-chapter-02 Your question inspires me to make some kind of short introduction podcast that gives more context. It's not so helpful to say "here's the book" when someone is just curious.
• 11 November 2020: In his model, centers themselves have form. So it doesn't map very well to a node/edges picture. But that network picture applies to project pattern languages. The patterns specify possible relationships of centers. From "Battle." pic.twitter.com/80aBvQknUt
• 10 November 2020: Designers lead our strategy as well. There’s a lot more context than the clip suggests.
• 10 November 2020: The enumeration of things like that is so vast that it departs from the territory of design requirements. Pretty sure that's why Alexander flips from requirements to "generative sequences." What are the things we can reproduce to generate a new kitchen with the same qualities.
• 10 November 2020: We don't even know what a good kitchen can "do" until we've been in one. For example having a deep conversation or reading a book aloud together while someone is cooking, and then completely switching modes to something else when someone else enters the room, while still cooking.
• 10 November 2020: Riffing on that a little more .... perhaps we could frame that by saying that tools are simpler than environments because they're embedded in = constrained by environments. Cutting a tomato in a kitchen is a farrrr more constrained problem than defining what a kitchen should be.
• 10 November 2020: FWIW ... I practice the "form follows function" approach when making tools. But I think it's because tools are way way simpler dimensionally than environments. To your point about architecture as living thing not object. The more the tool becomes an environment, it blurs.
• 10 November 2020: Powerful point. Notes on the Synthesis of Form said that the form resolves conflicts in the context, but the context itself cannot be completely spelled out and known. So the best you can do is find misfits and correct for them. I think that leads to the "site repair" pattern.
• 9 November 2020: Information from the wrong person is worse than wrong. It’s corrupt data.
• 9 November 2020: Re: "users" — when the user is different from the buyer, you can learn about consumption from them, not purchase. Problems in consumption can lead to firing later. ("They wouldn't use it.") But they don't explain how you got in the door. Need purchase timeline for that.
• 9 November 2020: I make every effort to screen like that so the interviews don't waste time. Then during the interview, ask if they looked around, if they shopped, if they put time into figuring this out. Leads you to see if they were personally struggling or someone else was going through it.
• 9 November 2020: Those are demographic segmentations. Not causal. Screen for the decision maker. Ask "was it your decision?" "Did you decide to do this or did someone else make this change?" Note that asks about the story, not about the demographic. Example from a recent real screener survey: pic.twitter.com/Qu1HJ780BE
• 9 November 2020: The number of people involved changes throughout the timeline. First thought happens to one person, active looking and deciding may involve more people. You'll hear "I" when someone is retelling the first thought/passive looking phases and "we" when they retell active/deciding.
• 9 November 2020: Newsletter #1 is out. • Differentiating instead of competing • "Unfolding" the interrelationship diagram Plus: • Product companies and "fixed output" • Naming things last → https://mailchi.mp/feltpresence/newsletter-1 (Thanks to all who helped with the spam issue.) pic.twitter.com/4ViVEioZEq
• 9 November 2020: Newsletter #1 is out. • Differentiating instead of competing • "Unfolding" the interrelationship diagram Plus: • Product companies and "fixed output" • Naming things last → https://mailchi.mp/feltpresence/newsletter-1 (Thanks to all who helped with the spam issue.) pic.twitter.com/ZpeK761Sxa
• 8 November 2020: Newsletter #1 is out. • Differentiating instead of competing • "Unfolding" the interrelationship diagram Plus: • Product companies and "fixed output" • Naming things last https://mailchi.mp/hey/ryans-newsletter-1 pic.twitter.com/SyEKhTWEV6
• 6 November 2020: Just email.
• 5 November 2020: Just hit 1,807 subscribers. Thank you! Looking forward to sharing in a new format. https://twitter.com/rjs/status/1324054181947297792?s=20
• 4 November 2020: Fewer drive-bys.
• 4 November 2020: Custom style.
• 4 November 2020: ⭐️NEWS⭐️ I'm moving my publishing from Twitter to a new (free) email newsletter. The goal: more context, less distraction, closer community. If you'd like to keep getting my thoughts and updates, please check out this explanation and subscribe here: https://mailchi.mp/hey/ryans-newsletter
• 4 November 2020: Yes. Not sure if it's an awareness issue. I think #2 and #3 both depend on the structure of the circumstance people are in.
• 4 November 2020: I have no interest in telling all product teams how they should operate. Or saying “this is the way to do product management.” We at Basecamp are impatient. We get very antsy if we haven’t shipped a meaningful customer-facing change recently. https://twitter.com/rjs/status/1324024636598792192
• 4 November 2020: The way we work at Basecamp (see http://basecamp.com/shapeup ) is not for all product teams. It’s for leaders of teams who think to themselves: “We can’t keep spending time on low-impact projects ... and we can’t seem to do a high-impact project without it dragging on forever...”
• 4 November 2020: I mean people saying “we like it” but then not using it. Or people saying “this is a problem” but not actually cancelling.
• 3 November 2020: UXDX https://twitter.com/uxdxconf/status/1323656416796827652?s=21 https://twitter.com/uxdxconf/status/1323656416796827652
• 3 November 2020: Thanks for all that. 👍
• 3 November 2020: Is there a part of the Burndown book you could point me to that describes how you make time for the team to talk to customers or how this fits into the steps of your repeating process?
• 3 November 2020: I don't think you can shape if you don't know how things are made and what's possible, because shaping is actually defining the core architecture of what to build. Eg. Jason at Basecamp doesn't program, but he understands very well how code, databases, UI etc wire together.
• 3 November 2020: Awesome.
• 3 November 2020: Learned a lot by looking closer at @cagan 's work today. I think we have different perspectives and work in different contexts, BUT ... I learned I must point out that shaping in Shape Up is done by people who know how to build! This is important and I'll emphasize it more.
• 3 November 2020: Oof yeah :)
• 3 November 2020: Another example. When we built Hill Charts in Basecamp, I wasn't at all confident that they would actually get used. So before we bet cycle time, I made a prototype in Numbers. Used it with one team on a real project to validate. Then shaped the BC feature version.
• 3 November 2020: I see spiking as an expensive but sometimes very worthwhile way to reduce risk. For example, I went to one of our senior programmers with a pitch I was working on. "Is this possible the way I'm assuming it is?" He spent 3 hrs spiking to demonstrate yes it's viable.
• 3 November 2020: I think I'm starting to see an assumption: Some people assume that shapers aren't engineers. Shaping requires knowing how stuff is built and what is possible with the technology.
• 3 November 2020: I thought assuming competence was a good thing! https://twitter.com/maszanchi/status/1323726297286221824?s=20
• 3 November 2020: One example from Basecamp: The idea to make our own WYSIWYG editor (Trix) came directly from our programmers. They uniquely understood both the potential of some new tech and the UX problems we struggled with. I think this is the kind of thing @cagan might be talking about.
• 3 November 2020: "Just consider the breakthrough innovations you use and love every day. Odds are that innovation originated from an empowered engineer." - @cagan in https://svpg.com/the-most-important-thing/ Love this as a challenge to the notion of shaping. Raises Qs about who does the shaping in what context.
• 3 November 2020: To be fair, we at Basecamp go further than that and outline the actual bones of the solution.
• 3 November 2020: Do you distinguish between talk and walk in customer feedback somehow?
• 3 November 2020: Great practice. https://twitter.com/dvassallo/status/1323716176208293888?s=20
• 3 November 2020: From your statements, I'm not sure you're considering how much problem solving and creativity is required to turn shaped work—at the right level of abstraction—into actual software. Shaped work is not a mockup. Not sure if you've read the book or not. It explains more.
• 3 November 2020: From what I've seen, there's a big gap between the pilot of a process like that and the ongoing reality. But the key point is to hear from real experiences to learn.
• 3 November 2020: I read that as an invitation to unpack what "aware of" and "care about" means. Does it mean a whole month dedicated to talking to customers directly? Does it mean a week-long intensive? Does it mean a day-long session? A 5-page writeup? A number? A thumbs-up thumbs-down?
• 3 November 2020: Anyone else? https://twitter.com/michiels/status/1323712892542308353?s=20
• 3 November 2020: Great distinction. If you pay attention to one person over time on Twitter, you can acquire amazing context. But if you sample across feeds, then trouble starts. /cc @ole_b_peters
• 3 November 2020: I'm asking for case studies because I am doubtful that many programmers who work on fixed-output products actually take a break from programming to go do customer research.
• 3 November 2020: People choose for themselves what they have time for. I've seen startups jump on Shape Up because they literally didn't have time for another low impact project or a high impact one that drags on forever. Depends on context and urgency.
• 3 November 2020: Relevancy is revealed by the market. I have my own ideas about what is important but I'm learning by how people react what resonates.
• 3 November 2020: Disagree. If they weren't responsible for the strategy, it's not fair to hold them accountable to the business impact. They should be accountable for the choices they made within the constraints of the strategy.
• 3 November 2020: Twitter, by design, makes it extremely difficult to establish and determine context. Leads to so many misunderstandings!
• 3 November 2020: New stock hopefully arrives today.
• 3 November 2020: Would love to hear more details.
• 3 November 2020: Defined in the book: https://basecamp.com/shapeup/1.1-chapter-02 It's about specifying the solution at the right level of abstraction, so there are constraints at the macro scale and still latitude in the specifics.
• 3 November 2020: The book is the canonical reference for what we do now.
• 3 November 2020: It's not their job to have impact on the business. It's their job to make stuff. Making quality code and interfaces is extremely hard, requires very scarce skill, and is undervalued.
• 3 November 2020: People say "your designers and programmers should all be talking to customers!" To them I ask: https://twitter.com/rjs/status/1323704144423780359?s=20
• 3 November 2020: No we don't decide by forum.
• 3 November 2020: I've heard that from other experts who've looked at it too. And I can see how you'd interpret it that way. IMO the more empirical test is to ask programers and designers who actually use the method if they feel better or worse about the work they are doing.
• 3 November 2020: Remix.
• 3 November 2020: Right. Shaping is where demand and supply meet.
• 3 November 2020: The output of shaping is a supply-side concept. But at a level of abstraction that leaves room for the teams to figure out the specific design.
• 3 November 2020: Good to call out this distinction! That's the world we at Basecamp work in and that's where we're coming from when we share.
• 3 November 2020: Agreed. We also don't tell designers/programmers exactly what to build. We give them lots of latitude to apply their own creativity. But we don't give them a blank page either and say "go figure it out." That doesn't help them. We lead with shaped work. https://twitter.com/cagan/status/1323703280933855232?s=20
• 3 November 2020: I'd be interested to learn from a case study if you have one where: 1. The company has a fixed-output model (the same product for all customers) 2. Is bigger than 5ish people 3. And all the designers and programmers interact with customers
• 3 November 2020: Ideas and visions are great when they are embedded in an accurate understanding of the context. That's what the shaping work does. It enables the team to channel all their creativity productively.
• 3 November 2020: Yeah. The important parts of the book aren't innovations. They were already all figured out by other people. The book just synthesized them. IMO this process keeps churning, with new presentations of similar ideas appearing every 10 years or so to fit with the changing context.
• 3 November 2020: I understand good leadership in general is hard to come by. Since shaping is about leading the direction of the product, not just keeping people busy, I think it's appropriate that it's a demanding position.
• 3 November 2020: I think that happens to everything. My career isn't based on Shape Up so I'm not worried about it. It's just a contribution that hopefully is helpful for people in our time now.
• 3 November 2020: This intro gives context for people who aren't familiar with Alexander's work. https://www.youtube.com/watch?v=XLsTZXT0FlM
• 3 November 2020: Because then designers would have to stop BSing. https://twitter.com/leemnelson_/status/1323692262920871936?s=20
• 3 November 2020: Key insight from Alexander (I'm re-reading "Battle".) The patterns in the shaped work aren't the work. The language generates the work. The actual configurations / relationships are found by the people doing the work. This kind of definition is not a specification.
• 3 November 2020: If product isn't "involving tech" then it's not product. The point of differentiating product from design is the integration of design + tech + biz. https://twitter.com/pvblivs/status/1323679451813732352?s=20
• 3 November 2020: We have less communication than big companies who meet all day every day. I have friends at a Fortune 50 doing Shape Up. The old way is fine if it’s fine for you, but this is not a scale bound thing.
• 3 November 2020: There’s a reason we talk about the church of finance, the church of scrum, etc. Anytime you get a certification and some tools (spreadsheet, backlog, etc) beware.
• 3 November 2020: Rails and Shape Up have something important in common. They’re both designed to preserve the experience of working on a small cross-functional intensely collaborative founding team. They appeal most to people who know what that experience is like.
• 3 November 2020: Lots of designers and product people talk about what they “believe” teams “should” do. Too many beliefs and shoulds. Too few case studies on the table showing what worked in practice. Shape Up is our contribution.
• 3 November 2020: C-level has to dedicate time to understanding the bigger picture and making macro trade offs. It’s a different role than individual contributor.
• 3 November 2020: I said there should be leadership, not that one functional group should dominate. DHH is part of leadership.
• 3 November 2020: We may end up doing the same threefold split across all “bucket” types (Teams and Projects are both Buckets in internal domain language). We’ll see.
• 3 November 2020: Exactly. For teams, a simple who’s on the team vs who has access for transparency is enough. For projects, I think we need the three-fold split because it affects how notifications go out.
• 3 November 2020: Unless you’re a team of three. https://twitter.com/isterin/status/1323660330942255110
• 3 November 2020: It depends more on the structure of the business than the people. Eg the model, where money comes from, whether inputs that need to be integrated are all within the firm or across firms, etc.
• 3 November 2020: At our scale (50+) people, “clients” doesn’t cut it. We have lots of internal people who should be able to see something but shouldn’t be spammed every time something happens. And mixing everyone who has access together creates confusion about who’s doing what.
• 3 November 2020: We reverse-engineered real “granting access” moments, found three patterns across many projects: 1. Who’s actually involved and responsible for this. 2. Who’s not involved, but needs to be informed of what’s going on. 3. Who’s neither but should have access for transparency.
• 3 November 2020: Short version is something like this... When I add someone to the project, set expectations for why they’re there. When I post on the project, help me notify the right people so it’s not noise to them. On Home, show the right faces so I know who’s actually involved in what.
• 3 November 2020: It’s about trade-offs. Eg. If I put everything in Notion, then I can’t go draw with the Pencil when I have a bunch of unclear thoughts. If everything is in Notability, I can’t type well. IMO “one place” is more important for collaboration and less important when working alone.
• 3 November 2020: It’s so much fun to have different points of view! In this clip @cagan and I represent two different extremes. The reality in practice is, of course, more nuanced. But starting on the edges is stimulating. Much more productive than echo chambering! Thanks @uxdxconf . https://twitter.com/uxdxconf/status/1323656416796827652
• 3 November 2020: Portfolio of options is what we bring to each betting table. I haven’t written the formal pitch yet. Talked it through a bunch with people and sketched it informally. I’ll consider sharing later when it’s formalized.
• 3 November 2020: Then, when it’s time to build, I switch tooling. If I’m building with others, I use Basecamp, Shape-Up style. Creating scopes with to-do lists etc. If I’m alone, I make a text document and capture tasks, group them into scopes, and strike things out there.
• 3 November 2020: Those three solve 80% of my shaping documentation problems. Notability is an extremely flexible catch-all. I sometimes reach for OmniGraffle for the desktop equivalent when I want a canvas to throw some ideas up and move them around.
• 3 November 2020: This Desktop Matryoshka Compaction technique is one of my favorite little hacks. Means my desktop can just accumulate junk as I work for short-term accessibility and speed but without turning into a long term mess. https://twitter.com/rjs/status/1323654995103854592
• 3 November 2020: 3) There are often random files. Maybe a Numbers file or a text doc with call notes. I create a folder on my Desktop for that named after the project. Maybe once a quarter, I “compact” the Desktop by moving literally everything into a folder called “Desktop” Matryoshka style.
• 3 November 2020: 2) In cases where I need to interview customers to inform the project, I have a custom-built app for inputing the data and distilling it through stages into patterns and takeaways. The app has data structures for that and organizes it all by project. (I’ll share in the future.)
• 3 November 2020: Short version ... I have a few main systems for this. 1) I use Notability on iPad as my notebook for every shaping project. I create a new “Subject” for the project and add notes/sketches there. Very messy and freeform but I can get back to anything. ... pic.twitter.com/5IdA30kBXS
• 3 November 2020: This information and research you’re talking about ... this is the input to the shaping work, yeah?
• 3 November 2020: I’ve shaped something very similar to that for BC4. No guarantees but it’s in the portfolio of options.
• 3 November 2020: Sounds like you are talking about managing all the information and state about the project. The “shaping” phase is just one part, the work you do before you commit to building something out.
• 3 November 2020: “Figuring out an ideal environment that suits shaping” For one person? What do you mean by that?
• 3 November 2020: The part about breaking work into scopes and tracking whether you are uphill or downhill is very useful for solo work. It helps you know what to do with the next block of time, better understand where you left off, and know what to pick off next.
• 3 November 2020: For working alone, the main thing is ask the questions to yourself: Am I shaping, or am I building right now? Am I committed to this piece of work or still evaluating whether it’s worth doing? How much time do I want to spend on this?
• 3 November 2020: Usually we understand the jobs better by contrasting them than by trying to increasingly pin one down. Eg. #1 is more about not stalling and moving forward, vs. #2 is more about managing load and capacity.
• 3 November 2020: Don’t try to read too much from a single statement. The statement is not the job, it’s just a headline. Eg. In this one, there are cases where the owner wants to make sure others are alerted when work is ready.
• 3 November 2020: I could’ve said “make sure it comes to my attention that....” to more clearly express the latitude, but that’s needlessly pedantic.
• 3 November 2020: The point is they need to know. How exactly that happens isn’t fixed or specified.
• 3 November 2020: It specifies what the solution should do, not what it should be. If constrains the solution side while still leaving a lot of latitude for the specifics.
• 2 November 2020: No limit on the runs. First big stock to fill back orders comes in today/tomorrow and we’ll keep reordering to stay stocked.
• 1 November 2020: It’s hard to carve the process in stone because C-level time is hard to get, hard to manage. So in the book I suggest just one betting table meeting during cool-down, where the person who shaped potential bets pitches them. 1:1 chats w/ decision makers in advance are an upgrade.
• 1 November 2020: Depends on whether the shaper has regular communication w/ people at the betting table or not. Betting table = decision makers, so they’re busy. Sometimes you can’t get their time in advance, so you start from zero. Other times, you can discuss a few times leading up to it.
• 29 October 2020: Ah I misunderstood you. I see what you mean. Yeah the amount of energy depends.
• 29 October 2020: The job is the movement from struggling moment to desired outcome.
• 29 October 2020: All jobs are like that. Without the struggling moment there’s no job.
• 29 October 2020: Just wrote up results from a short demand-side research project on why people buy kanbans and in what situations they are most valuable. Two situations stood out. pic.twitter.com/0M0bAkIl76
• 29 October 2020: We’re not selling on Amazon. You can buy direct from http://basecamp.com/shapeup .
• 29 October 2020: forwards to designer for cover of next print run
• 29 October 2020: The first stock flew off the shelf. For those of you waiting on a backorder, we’re expect the fulfillment house to start shipping new stock on Tuesday. https://twitter.com/rjs/status/1321560810834038784
• 28 October 2020: The book is out in full-color paperback! Shape Up: Stop Running in Circles and Ship Work that Matters For software teams struggling to ship meaningful projects, and product leaders who want to have more time to think strategically. https://basecamp.com/shapeup
• 27 October 2020: Infuriating for people who believe stats should be used for ... you know ... accuracy. But very common. "Look, I built a cool thing out of math to get your attention!" is orthogonal to "Look, I built a rigorous robust model to find the truth."
• 27 October 2020: All the evidence points to a product that succeeds based on traffic, not accuracy—with all the incentives that entails—and is aimed at people who aren't very critical about accuracy. Stats as narrative/entertainment, not science.
• 27 October 2020: Looking at the wider context, I suspect 538 and prediction markets serve different purposes with similar language. Prediction Markets are about outcomes because of the $ involved. 538 is about "current status" because of the traffic involved. It's "news" not truly prediction.
• 27 October 2020: Another one. pic.twitter.com/mXmkg53gtV
• 27 October 2020: From a side project (an app for doing demand-side interviews and analysis)... Experimenting with new formats for presenting shaped work, inspired by pattern languages. pic.twitter.com/mGag9JGita
• 26 October 2020: Most people doing Shape Up aren’t using Basecamp.
• 25 October 2020: Eg I don’t have to state “light from two sides of the room” to a good architect. It’s not project-specific.
• 25 October 2020: Speculating a little here.... but IMO the more off-the-shelf a pattern is, the less important it is to state it in the language. It becomes part of the toolkit of the person who designs a realization of the language.
• 25 October 2020: The value of the project comes from the unique integration. May include off the shelf patterns, but if everything is completely off the shelf then you’re doing assembly not design.
• 25 October 2020: Also in this case, sometimes the sketch came first, and it took work to figure out what mattered about the sketch and express it as some patterns.
• 25 October 2020: Worth distinguishing personal process from the form a deliverable takes. Here the written form (in more detail than this outline) is the deliverable, not a wireframe. Key difference.
• 25 October 2020: FYI original Tweet is about project-specific patterns. Not off-the-shelf libraries.
• 25 October 2020: In another words, a wireframe or mockup is one possible realization of the patterns.
• 25 October 2020: I could draw this as a wireframe. (And it might be helpful to sketch a suggestion for how they all go together...) But the pattern language is what GENERATES the wireframe. https://twitter.com/rjs/status/1320421045757714435
• 25 October 2020: Example of shaping as a pattern language. Each of these has a rough design. There’s some variety in the scale of patterns. They network together to define a whole project. pic.twitter.com/UrcW4u0eUA
• 25 October 2020: (Maybe you knew all that, and we just were using the word “crossing” differently. Helping someone in Passive Looking is different from trying to get them to cross from Passive Looking to Active Looking.)
• 25 October 2020: Same with Active Looking to Deciding. We can answer all their questions in Active Looking and help them make progress. But they won’t be ready to made trade-offs and start Deciding until Event #2 happens to them.
• 25 October 2020: As I understand, if somebody is in Passive Looking, we can help them to frame the problem. Give them language or stories that show how other people dealt with it. But that doesn’t mean we’re getting them to Active Looking. Event #1 does that.
• 25 October 2020: We don’t help them cross steps. They cross steps on their schedule. This is a fundamental point. Event #1 and Event #2 create the urgency for them to move forward. Those events aren’t created by the sales person, they happen in the buyer’s life. pic.twitter.com/PYt5G4D0pP
• 25 October 2020: Which means that breadboards and fat marker sketches are actually tools for sketching patterns, not complete interfaces. Makes more sense. https://twitter.com/rjs/status/1320409892952395783
• 25 October 2020: Yeah. I had a huge a-aha once I understood project-specific pattern languages.
• 25 October 2020: Working on a side project... First cut of shaping included changing an editable matrix to be read-only, rotating 90°, + color-coding. Realized I can’t rotate 90° w/o upsetting other screens. Removed that from the scope to orthogonalize. This is pattern-level decision making.
• 25 October 2020: Pretty sure some future version of the “Find the Elements” step of Shape Up (Ch 4) will become “Draft the Patterns.” Why? That’s what the “elements” actually are. They’re little problem/solution chunks at the right level of abstraction that compose into the overall shape.
• 25 October 2020: Did you read Demand-Side Sales? It’s the buyer’s timeline, not the seller’s.
• 25 October 2020: I’ve had situations where I was talking to someone in passive looking. They were complaining but not ready to start doing anything.
• 25 October 2020: My first instinct is to question when that “dominant design” framework is applicable and relevant. For that I think Clay Christensen’s theory of modularity and interdependence would go a long way. Check the Innovator’s Solution for a good treatment of that.
• 23 October 2020: We're going live now. https://twitter.com/rjs/status/1318641908604915715?s=20
• 22 October 2020: Do people use it?
• 22 October 2020: "He's great at engaging with readers." What do you see that tells you that?
• 22 October 2020: Good tip.
• 22 October 2020: Do you know how the Discord turned out?
• 22 October 2020: How?
• 22 October 2020: Thinking about changing formats .... from Twitter to a free newsletter. Have any newsletter authors out there found a way to get feedback and reactions from readers? I like the calm of email instead of Twitter zania, but anticipate radio silence and "is this thing on?" feeling.
• 22 October 2020: In the book, Bob suggests giving different demos to people depending on where they are in the timeline. Q: How do you determine which phase of the timeline somebody is in when they approach you? What do you ask them?
• 22 October 2020: Fascinating. From @bmoesta 's Business of Software talk: In the Passive Looking phase, prospective buyers learn to speak the language of the solution. Obvious in retrospect but wow: the solution always has unique language and people have to learn it! https://businessofsoftware.org/2020/10/demand-side-sales-101-bob-moesta-online/
• 21 October 2020: Build dependencies are different from design dependencies. In build, foundation → frame → rooms. In design, rooms → frame → foundation. Different sequences.
• 20 October 2020: I want to be pulled in for certain things. It's domain-dependent.
• 20 October 2020: "Push" is what the app does to the message. "Pull" is what the message does to the person. https://twitter.com/jasonfried/status/1318590689110761472?s=20
• 20 October 2020: "there is not a beauty vs function tradeoff"
• 20 October 2020: It’s not reductive.
• 20 October 2020: It’s a matter of harmony and wholeness. See Alexander’s 15 properties.
• 20 October 2020: No, particular forms can definitely be ugly. It’s not all relative.
• 20 October 2020: If you have to define beauty you are missing the point. It’s a feeling not an idea.
• 20 October 2020: I still don’t understand it, but I’m fascinated by this and I think it’s maybe true. https://twitter.com/normonics/status/1318637300860026880
• 20 October 2020: Diseconomies of Scale Paper: At small scale "close proximity of productive activities along with informal networks of communication and production enable many functions to be carried out ... easily and spontaneously [without] intermediary functions." https://twitter.com/wrathofgnon/status/1151041726498390016?s=20
• 20 October 2020: I don’t know any good aggregators. I just follow authors I like and sometimes bump into links to things because of who I’m connected to on Twitter.
• 20 October 2020: For a simplified but workable intro to this for software projects, see: https://basecamp.com/shapeup/1.4-chapter-05
• 20 October 2020: Estimates of how long it takes to build software aren’t normally distributed. Because of opacity and cascade effects across the interdependencies of both implementation and scope (that is, they’re hard to see in advance and they tend to snowball).
• 20 October 2020: This fundamental paper by @nntaleb , @yaneerbaryam and @DrCirillo also applies fully to software estimation. “On Single Point Forecasts for Fat-Tailed Variables” https://arxiv.org/pdf/2007.16096.pdf pic.twitter.com/X0EedYjxYV
• 19 October 2020: So cool to see success stories like these. A big win that only took six weeks ... it was probably waiting to happen ... but needed more focus and constraints to get it done. https://twitter.com/GavinHammar/status/1318238245524733954?s=20
• 18 October 2020: Agree. Also because there isn’t one “sense” to make. Turning something into a workable representation requires actively making choices.
• 17 October 2020: I’ve done well over 100 interviews. Just flipping through these case studies, I see some points of technique that lapsed that I‘m excited to tighten up again. https://twitter.com/rjs/status/1317461294484770816
• 17 October 2020: Got to the second half of @bmoesta ’s “Demand-Side Sales 101” today. The most detailed breakdown of demand-side interviews I’ve ever seen. Amazing. Going to be recommending this now to people who ask about doing interviews. Slow-motion through three case studies with commentary. pic.twitter.com/aPeXmY4Bre
• 16 October 2020: Yes. We do the same thing at Basecamp. (See Shape Up Ch 11: https://basecamp.com/shapeup/3.2-chapter-11 ) https://twitter.com/germsvel/status/1317078515708284931?s=20
• 16 October 2020: What are the architectural consequences? Fascinating to think the post-COVID world will be neither one where everyone works from an office NOR one where each person works alone from home. At Basecamp’s office, the highlight was a few small cozy rooms for 2-4 people to collab. https://twitter.com/awilkinson/status/1317104257921818627
• 16 October 2020: Yes. Quality is judged by where the consumer is in their process. What they're ready for and what they define as the next step of progress is the true metric. There's no ultimate metric.
• 16 October 2020: (I may be on the wrong thread here. This is re: the learning from Rogan vs a TA thing).
• 16 October 2020: A professional academic is going to have a very hard time appreciation what people learn on podcasts etc because from their point of view it's inferior. But from the podcasts listeners pov the competition isn't the academic explanation, it's nothing at all.
• 16 October 2020: It's a perfect example of Clay Christensen's Innovator's Dilemma. The incumbent on the high-end of the performance spectrum can't even see how the new low-end competitor is valuable because it's so much "worse." But only looks like that when looking down, not looking up.
• 15 October 2020: This convention is like a micro inline hill chart. Distinguish the solidly known elements from the elements with unknowns. https://twitter.com/rjs/status/1316829815954198529?s=20
• 15 October 2020: Yes. Common pattern: discover some work, write it down, reconsider it, mark ~.
• 15 October 2020: We don't do anything around the certainty convention. That's a new thought. We use the ~ all the time. Often on individual items, sometimes on a group.
• 15 October 2020: A Pattern Language marks patterns with * or ** to indicate how certain the authors were about the validity of the pattern. Seems that kind of "how sure I am" convention is widely useful. Sort of like the "~" trick we use at Basecamp to distinguish nice-to-haves from must-haves.
• 15 October 2020: Example: From: Weekly in-person meetings + a Google doc task list + a projector + text messages between meetings To: Weekly video meetings + Basecamp
• 15 October 2020: Products rarely compete 1-1. Each product has "holes" that get plugged with compensating workarounds and tools. People design bundles to do the job and the bundles change when they switch.
• 15 October 2020: Unexpected innovation for @_buildingbeauty due to Covid. Now students who participate remotely build projects in their homes and communities, "whatever is most in need of repair where they live," instead of at the school. Described in this podcast: https://entrearchitect.com/podcast/byb/christopher-alexanders-legacy-at-building-beauty/
• 15 October 2020: It’s about knowing something is done, not automating.
• 14 October 2020: A "deliverable" is something somebody produces for somebody else in a project. Like a design, a proposal, a report, a piece of code, etc.
• 14 October 2020: Fascinating JTBD interview w/ a kanban adopter just now. He wanted his contractors to move cards instead of emailing him deliverables. Why? To bill faster. "Then I can bill in increments and keep cash coming into the company instead of this start stop start stop."
• 14 October 2020: Question from @jeffmli : "How much time/effort do you guys usually put into the 'Shaping' process? The book said it's a separate track from the 'building' process." https://twitter.com/rjs/status/1316418887009828864?s=20
• 14 October 2020: The set of things in play has a wide distribution — some things get shaped in a week, other things take years to finally come together. The key thing is there has to be something meaningful and timely to do in the next cycle. That creates urgency to finish something every round.
• 14 October 2020: Ridiculously high content/min in this new podcast with @bmoesta . Like a tour of looking at the world through the job-to-be-done lens. Plus sharp details on differences between sales/marketing and a preview of his next book on the skills of an innovator. https://overcast.fm/+GPx5UuqH8
• 14 October 2020: Yes good special case.
• 13 October 2020: When people talk about selling to business, for some reason they often only think about giant companies. That’s a niche! The world is full of small businesses.
• 13 October 2020: There are a lot of business that aren’t “enterprise.” Basecamp’s customers are all businesses.
• 13 October 2020: Businesses buy all kinds of things off the shelf. There's nothing inherently different about B2B.
• 13 October 2020: Yes. All products and services solve problems. The difference is whether the business produces the same fixed output over and over or does something custom each time. Very different processes, cost structure, and scaling properties.
• 13 October 2020: All products and services “solve problems.” The difference is whether the business produces the same fixed output over and over time some custom for each client. Very different processes, cost structure, and scaling properties.
• 13 October 2020: Exactly my point. That’s a different business model than selling a fixed product to every customer.
• 13 October 2020: When product people ask about how to communicate roadmaps to customers, it makes me ask: what are they selling? A product company sells things they already made. If you're selling things you didn't make yet, you probably work in a different business model, like a solution shop.
• 13 October 2020: "Sometimes, the teams that go the fastest are the teams that look very calm. They are not constantly on some methodology treadmill or on some procedural clock that goes ding! ding! ding! every five seconds." - @dhh https://medium.com/computers-are-hard/computers-are-hard-building-software-with-david-heinemeier-hansson-c9025cdf225e
• 13 October 2020: This interview with @dhh is amazing. Where Agile went wrong, thinking in appetites instead of estimates, and much more. https://medium.com/computers-are-hard/computers-are-hard-building-software-with-david-heinemeier-hansson-c9025cdf225e pic.twitter.com/KddGxFKTKs
• 13 October 2020: Of course. We’re aware of many non-software competitors. The kanban thing is targeted — it came up in some other interviews and we want to learn more.
• 12 October 2020: Yeah. That's a good example of the kind of factors that aren't so obvious from the surface.
• 12 October 2020: Just sent them an email.
• 12 October 2020: Yeah. I've heard exactly that from a number of people. One of the goals of the interviews is to learn when that's true — under what circumstances.
• 12 October 2020: Just sent out a screener to people who cancelled Basecamp for some interviews. Example of questions and answers. Since this is a JTBD screener, they're mostly about timing and who made the decision. pic.twitter.com/OzolbSUkkB
• 12 October 2020: This could be a good signal/noise metric... For an onboarding message that people are supposed to read, instrument how many clicked "next" or "ok" after enough seconds have elapsed to actually read it.
• 12 October 2020: Real life is more complicated than that. It's not just about priority. It's also about "I just finished a really hard task. Give me a few easy things because I still have an hour left before I go home."
• 12 October 2020: Example of social/emotional non-consumption: The to-do assignment feature works exactly as it should. But when asking a peer to do something, "assigning" isn't appropriate. So the ask happens in a chat instead and is hard to track. https://twitter.com/rjs/status/1315700879107018754?s=20
• 12 October 2020: Sketch of WIP "portfolio of options" for BC4. - Raise signal: Surface things that are buried/implicit - Social/emotional: Fix non-consumption driven by non-functional factors - Market gap: New things BC should do for competitive reasons Not universal categories — of the moment. pic.twitter.com/GA3WsC71v5
• 12 October 2020: Good definition from @normonics in today's Applied Complexity Newsletter (recommended). pic.twitter.com/jVBmFIjG0q
• 10 October 2020: If I were Twitter, the project I’d start building on Monday would be closed communities. A feed that requires $ and/or an application process to participate. Admins can boot people out. This one thing could create very high signal sub-communities.
• 9 October 2020: Awesome. Thanks for sharing.
• 9 October 2020: Lately I’ve had great experiences “touring” concepts to people, one-on-one. I’d rather have four one-on-ones than a single group meeting (which we never do anyway). Deeper exchange and I gain more perspective.
• 9 October 2020: In general, don’t post to the company. Make a BC team just for the betting table. You can tour the pitch, 1:1, to anybody to get feedback first. I sometimes post to the whole company, but we have cultural context around that now. I invite feedback as 1:1 chats off-thread.
• 9 October 2020: Top priority!
• 9 October 2020: “Q: Are you planning on writing about your experiences with Shape Up?” https://twitter.com/adamwathan/status/1314638805115248648
• 9 October 2020: A system designer differs from a “designer” by setting the boundary of what’s in/out. Within that, there are a million hard things to get right that require a designer’s expertise. They differ from a PM because design is about making trade-offs. Mgmt is about doing it all. 3/3
• 9 October 2020: We can call the missing role, upstream from programmers, the “system designer.” This is somebody who uses time and resources as constraints to make trade-offs about what to build. Their inputs are demand-side (what people value). Their output is supply-side (shaped work). 2/3
• 9 October 2020: A friend’s software startup is all devs, no designers. Devs complain that requirements (“stories”) aren’t defined enough. There’s confusion about who to hire to fix it. “Designer” is too broad, too visual. “Product owner/manager” only makes sense at larger-scale firms. 1/3 ....
• 8 October 2020: Much of the real work people do in a day is not represented in any system and couldn’t be. It comes up through conversation or by bumping into unexpected things. That’s why the pattern describes that behavior: they write it down and immediately cross it off in a text document.
• 8 October 2020: Tried writing up some shaped work as a pattern language this week. The idea is to give more understanding of the "why" and more latitude to the team if we end up making the bet. Curious to see how it works out. pic.twitter.com/vReFMfH6Zn
• 8 October 2020: Shape Up Chapter 5 touches on thin-tailed vs fat-tailed risk. In practice, fat-tailed design risk is where you go "oh ... we need to figure that out now" because if we don't, there's a hole in the design and all expectations about finishing on time go out the window.
• 8 October 2020: The real-life version of this: When @jasonfried and I were shaping together in a room, there'd be this moment where I'd say: "But what about _____?" and he'd go "I don't know, but I'm not worried about that." "Not worried about that" = a closed unknown. https://twitter.com/rjs/status/1314231508522225665?s=20
• 8 October 2020: Trivial example: a button in a fat marker sketch has latitude for the exact type, color, proportion. Big, riskier example: A task feature could be editable like a text doc or a stack of draggable objects. While still in shaping, there can be latitude to prototype/decide which.
• 8 October 2020: We've talked before about open-ended unknowns versus closed/bounded unknowns: when there might be no solution vs. when we know there's some solution but not the details or which is best. "Latitude" — room for changing the shape / design — is the range of a closed unknown.
• 7 October 2020: It’s a question of whether you understand the technical interdependencies or not. Involve technical experts in shaping, and do some spiking to learn if nobody knows exactly what’s possible. Details in this chapter: https://basecamp.com/shapeup/1.4-chapter-05
• 7 October 2020: Everything is a “must-have” until you run out of time or money.
• 7 October 2020: This is even more important with clients. Don’t just negotiate the price and timeline. Negotiate the shape of the work. Clients don’t know for themselves where the must-haves separate from the nice-to-haves until they’re faced with constraints. https://twitter.com/evelasco/status/1313897627566641155
• 7 October 2020: The alternative is to promise things you can’t with good odds deliver.
• 7 October 2020: Of course you can.
• 7 October 2020: We model that as uphill and downhill phases. Yes, sometimes we’re figuring out what to do and this is important. But also we can’t be learning all the time — we need to decide what we’re doing and go do it.
• 7 October 2020: Factoring / Decomposition / Orthogonality ... whatever you call it ... is breaking the work according to the ANATOMY of the work, not two-week nibbles. When we define six-week projects, we define what “done” means, what “shippable” means, for a separable unit of the whole.
• 7 October 2020: Building a big project: a new product, a major redesign,... 2 weeks at a time is nibbling and wandering. It drags on and on with no end. Planning a whole six months+ is fortune telling: always turns out wrong. In between? Factoring. Decomposing. Orthogonalizing. 1/n
• 7 October 2020: Just gave a talk at #UXDX . Something fundamental came up. People often treat the work as fixed, and add more and more people and time to get it done. At @basecamp , we treat the people and time as fixed, and redesign the work so it can be done within that.
• 5 October 2020: For future reference, the ungoogleable native web version of A Pattern Language is here: http://www.iwritewordsgood.com/apl/set.htm (Thanks @harshakishan )
• 5 October 2020: Yes!
• 5 October 2020: No, but thanks. That one is incomplete.
• 5 October 2020: Not it. It's an ungoogleable web native version.
• 5 October 2020: Does anybody have a link to that ungoogleable online version of A Pattern Language?
• 5 October 2020: Yeah it bottoms out with demand. Demand has to preexist supply. Without energy and intent, nothing happens.
• 5 October 2020: Too much shape latitude makes a bet risky. The extreme of too much latitude is “unshaped work.” But sometimes we don’t know which shape is the right one. That’s where spiking and prototyping strategies come in.
• 5 October 2020: Design latitude is variance in how to do it. Shape latitude is variance in what’s in/out.
• 5 October 2020: In short: The supply side recruits demand-side behaviors. The demand side recruits supply-side affordances.
• 5 October 2020: Been talking a lot about design latitude. That’s where the shape leaves degrees of freedom for designers to make decisions. A level up, we can talk about shape latitude. Shape latitude is the room for hammering the outer scope of the whole project.
• 5 October 2020: /cc @bmoesta on the yin/yang of JTBD and Shape Up.
• 5 October 2020: “Clean” as free of dependencies — love that. Reminds me of how it’s hard to get a pitch through until it becomes a “straight shot.”
• 5 October 2020: If so, it may work to think of a pattern as the recruitment of resources toward some end. A demand-side pattern recruits elements of supply toward some end. A supply-side pattern recruits things people do / try to do towards some end. Interesting mutual dependence.
• 5 October 2020: This latter example sets requirements for a possible solution (fast entry, no filing, stays around after completing it, nobody else can see it...). Those are candidates for the supply-side patterns that enable performing the demand-side pattern. Maybe.
• 5 October 2020: That said, it seems possible to define demand-side patterns one layer back. These are patterns in what users do, orthogonal to the solution design. Eg. people often write a task into a text doc and immediately strike it to record something they just did but didn’t plan to do.
• 5 October 2020: Thinking about pattern languages as demand vs. supply side. Patterns embed demand-side knowledge (the ‘problem’) but are partitioned from each other according to the boundaries of what the designer should do (“light from two sides”, “entrance transition”). They’re supply-side.
• 5 October 2020: Interesting. Law and coding have a lot of overlap.
• 5 October 2020: Not in the "pulling the slot machine" is fun sense—in the sense that maybe more volatility enables the performer to reach more interesting regions of possibility space.
• 5 October 2020: Don't know how to frame this ... but I've also been wondering if there's something enabling about volatility in performance (of a performer/artist). Kind of a stretch, but I've noticed my favorite songs are by artists whose broad repertoire I don't evenly appreciate.
• 4 October 2020: And when thinking categorically, categorize trajectories. See ‘The End of Average’: https://www.amazon.com/End-Average-Succeed-Values-Sameness/dp/0062358367
• 4 October 2020: Think dynamically—in trajectories—not statically in categories. https://twitter.com/RobSnyder1/status/1312745653588688897
• 4 October 2020: Good summary of three essential points. https://twitter.com/robsnyder1/status/1312745652099649536
• 2 October 2020: For example #4 doing tasks is a drag, so a picture of a loved one or inspiring quote can give you extra energy to get through the day.
• 2 October 2020: Each pattern describes a problem/solution pair. See Christopher Alexander’s work. https://youtu.be/XLsTZXT0FlM
• 2 October 2020: The best form for a pitch — which I don’t know how exactly how to create yet — is probably a project-specific pattern language. Current work in progress. Each of these has a corresponding small sketch, which adds up to a whole without specifying a wireframe. pic.twitter.com/ChZuPEo6Cl
• 2 October 2020: In software development, “other people” and “future me” are often equivalent. Eg. make the code readable for ______. Eg. leave design latitude for ______ to decide.
• 2 October 2020: Whether positive/negative is better is contextual. Negative defines a boundary that gives other people latitude to decide. Maybe “add to bottom” is better than “add to top.” Or a separate “triage” zone. Both satisfy the req. Positive trades off the latitude for specificity. 2/2
• 2 October 2020: Interesting shaping question: when to state in the negative vs. positive. I’m shaping a task management feature now. A pattern could be “no filing when adding.” That’s negative: what not to do. Positive could be “add directly to the top.” 1/2
• 2 October 2020: Source: https://overcast.fm/+aQSGo0398
• 2 October 2020: Learned on a recent @bmoesta podcast: Re: First Thought > Passive Looking > Active Looking > Deciding... In Active Looking, all the options are orthogonal and additive. I want this AND this AND this AND this. In Deciding, you face reality of trade-offs and choose this OR that.
• 2 October 2020: This is the most in-the-weeds (in a good way) podcast about @bmoesta ’s new book and the buying timeline so far: https://overcast.fm/+KmqppKBbo
• 2 October 2020: A Shape Up adopter @JuJoDi created this solid cheat sheet: https://medium.com/@jjdickow/implement-shape-up-cheatsheet-8fb08fffcadc
• 2 October 2020: The Wolfram Physics project produces the most beautiful graphics. https://writings.stephenwolfram.com/2020/10/faster-than-light-in-our-model-of-physics-some-preliminary-thoughts/ pic.twitter.com/71LkcL1kOx
• 2 October 2020: We’re hiring a designer at @basecamp . Details: https://m.signalvnoise.com/basecamp-is-hiring-a-product-designer/ pic.twitter.com/eA5RBqsBKQ
• 2 October 2020: Rare opportunity for a designer to join us. https://twitter.com/jasonfried/status/1312052051208105990
• 29 September 2020: “Marketing is taught to define the market by ‘who’ because we advertise to ‘who’: what’s your age, your income, where do you go, what car do you drive... “All this stuff. We triangulate and correlate everything. But it doesn’t cause people to do it.” https://overcast.fm/+aQSGo0398
• 28 September 2020: No we don’t have any process there.
• 27 September 2020: “Buildings come and go but get the scale right and you’re safe: the rest can be fixed.” Applies to a lot of things. https://twitter.com/wrathofgnon/status/1310198477926707201
• 26 September 2020: RT @jonathanallard: @rjs Personally, the word makes me think of deboning a chicken or dissecting something: it’s messy, it’s all over the p…
• 26 September 2020: Love that. I much prefer that kind of messier, hands-on term over the aloof “sensemaking.”
• 25 September 2020: New @EdwardTufte book! https://twitter.com/EdwardTufte/status/1309419234783526912?s=20
• 25 September 2020: https://twitter.com/rjs/status/1309234547205251072?s=20
• 24 September 2020: https://twitter.com/rjs/status/1309234547205251072?s=20
• 24 September 2020: We'll be selling it independently. Sign up here to get notified: https://basecamp.us2.list-manage.com/subscribe?u=2a145c60b16248b65e46a799a&id=8d22f5d9c4
• 24 September 2020: Actual copy in hand! Look incredible thanks to @AdamStddrd 's design. pic.twitter.com/hDJqNaR8ZG
• 24 September 2020: Asking because w/o a fixed time box, the design is never really “settled.” With a hard time box, you’ll have both (1) a settled design and (2) limited time. Due to (1) QA waits until design is settled to test, (2) no hard spec because not enough time to make it. That’s my take.
• 24 September 2020: Very smooth. Some service called http://covid.menu or something like that handled it for many places in Mexico City.
• 24 September 2020: Yeah. Could become a differentiator post-Covid. Paper menu = fancy instead of normal.
• 24 September 2020: Yes. Perfect example of how we don't value new things without a struggling moment.
• 24 September 2020: Innovation from Covid: Nearly all the restaurants I've seen in Mexico City and Oaxaca replaced their menus with QR codes. Seems likely to stick after the pandemic. Easier to update the menu, less to clean and shuffle around. And not at all a bad customer experience.
• 24 September 2020: Do these projects have a fixed time box and a hard deadline?
• 24 September 2020: Are you working in cycles a la Shape Up?
• 24 September 2020: I meant of deciding when and where QA fits into the process and what their inputs are.
• 24 September 2020: Huge difference. https://twitter.com/ichverstehe/status/1309015290529935361?s=20
• 24 September 2020: Who’s in charge?
• 23 September 2020: Practice is more helpful than definition tuning.
• 23 September 2020: Nitpicking. Doesn’t really matter.
• 23 September 2020: It’s an interrelationship diagram. https://twitter.com/rjs/status/1300559611049566208?s=20
• 22 September 2020: https://twitter.com/rjs/status/1308479543368327168?s=20
• 22 September 2020: This is the story that got me into job-to-be-done theory nine years ago, when I first heard Bob tell it to @asymco on the Critical Path podcast. The one about the dining room table. It’s in the book: https://www.amazon.com/Demand-Side-Sales-101-Customers-Progress-ebook/dp/B08FRRF68Q pic.twitter.com/BjW7qZGb2E
• 22 September 2020: Limited edition for the first batch.
• 22 September 2020: So smart. https://www.amazon.com/Demand-Side-Sales-101-Customers-Progress-ebook/dp/B08FRRF68Q pic.twitter.com/IorFNn3bZO
• 22 September 2020: So much to unpack. Here Bob and Greg connect the demand-side and supply-side along the buying timeline. https://www.amazon.com/Demand-Side-Sales-101-Customers-Progress-ebook/dp/B08FRRF68Q pic.twitter.com/iAdTWO4SDf
• 22 September 2020: “Without the first thought, there is no demand.” Gold from @bmoesta ’s new book ( https://www.amazon.com/Demand-Side-Sales-101-Customers-Progress-ebook/dp/B08FRRF68Q ) pic.twitter.com/B2oLeDjRYc
• 22 September 2020: We’re not :)
• 22 September 2020: From the forum: “We’re about to adopt Shape Up on our team. . . . “I’m curious if there are any stories from folks who have tried and failed to implement Shape Up or failed to get great results with it? What went wrong? Any post mortem lessons for us?” https://discourse.learnshapeup.com/t/any-stories-of-shape-up-adoption-failures/550
• 22 September 2020: Final proof is on its way. pic.twitter.com/vc0uf7UFnS
• 22 September 2020: The Kindle edition of @bmoesta 's new book on sales is out today. https://twitter.com/bmoesta/status/1308392442404786178?s=20
• 22 September 2020: See this paper for details on how a solution shop differs from other business models, and how each business model necessitates different processes: https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.703.5&rep=rep1&type=pdf For an accessible summary, see Clay Christensen’s “The Innovator’s Prescription” pic.twitter.com/HZTHHgfWTL
• 21 September 2020: Thank you.
• 21 September 2020: Anyone have a good reference for @claychristensen ’s three types of business models: solution shop, value-adding process, and facilitated network? There’s a good presentation in his book on health care (Innovator’s Prescription) but looking for any others. Thanks.
• 19 September 2020: No. They are different models with different processes that make money and allocate resources in different ways.
• 19 September 2020: A company that makes one thing and sells it over and over again to different customers. Vs. a company that makes things to order.
• 17 September 2020: They call themselves product companies but if their feature development choices depend on sales deals then they aren’t.
• 17 September 2020: This point seems to be under-appreciated: You cannot operate like a product company unless you have a product business model! If you are serving a few high-priced clients, that is not a product business. That’s a solution shop!
• 17 September 2020: We are a product company. It’s a different business model with different processes.
• 17 September 2020: That’s simply what design is. That’s the work!
• 17 September 2020: What do you mean by feature integration?
• 15 September 2020: I signed up. https://twitter.com/bmoesta/status/1305466973703278592?s=20
• 13 September 2020: It’s not all about the customer. Focus on what the decision maker cares about, and look for overlap.
• 12 September 2020: Another take: https://twitter.com/rjs/status/1257808477956616192?s=20
• 12 September 2020: Yeah. The difference in your two examples is the amount of latitude in the direction given. I called that "level of abstraction" here: https://basecamp.com/shapeup/1.1-chapter-02
• 12 September 2020: Re: special cases where Product Managers do in fact run the show and don't just herd cats. https://twitter.com/rjs/status/1304885479980978177?s=20
• 12 September 2020: Agree with all that. My qualm and the reason I merrily poked at PMs yesterday is because there's way more "shoulds" than reality when you look across the industry. 100% of programmers program. 100% of designers design. What % of PMs have actual strategic influence?
• 12 September 2020: Beautiful and inspiring thread (dig down for more and more photos and details). An example of what Alexander called Positive Outdoor Space. https://twitter.com/wrathofgnon/status/1199529574146568192?s=20
• 12 September 2020: I don’t coordinate or manage or align other peoples’ time and effort.
• 12 September 2020: I don’t know! The point isn’t about the name of the title, it’s more about the bundling of responsibilities and expectations. See below. I have seen some people define/become a “Shaper” role, which is a mix of strategy and senior designer. IMO betting should require a stake. https://twitter.com/rjs/status/1302067841315741697
• 12 September 2020: Relevant to today’s discussion about PMs: https://twitter.com/rjs/status/1302067841315741697
• 12 September 2020: I wonder how representative that is of PMs in general.
• 12 September 2020: Excellent counterpoint. https://twitter.com/isterin/status/1304587505283592200
• 12 September 2020: “Product Management is happening whether you have someone with the title or not!” So is typing. Shall we hire some typists?
• 12 September 2020: Your response exactly fits what I’m hearing. It’s aspirational. “That’s what you and Jason do!” But I’m not a PM. And he’s not either. He’s a CEO. And I’m a shaper.
• 12 September 2020: I’m mostly seeing PMs in the wild working as coordinators, responsible for “alignment.”
• 12 September 2020: In reality very few Product Managers actually decide what to do. It’s coming down to them from a stakeholder.
• 12 September 2020: ⭐️ Options, Not Roadmaps On how roadmaps ignore uncertainy, create expectations, and cause guilt. And how we think about planning differently. https://m.signalvnoise.com/options-not-roadmaps/
• 12 September 2020: Second strongest defenders of the Product Management role: People who make their living coaching/training organizations about PM.
• 12 September 2020: The people who defend the Product Management role the most usually have the least influence on products. It’s an aspiration, not a reality. People who say “But Steve Jobs was the PM!” miss a small detail: he was the CEO. https://twitter.com/rjs/status/1304490022645587968
• 12 September 2020: Because it misses the point and shows you didn’t listen to the audio. The audio clip says that Steve Jobs was the PM.
• 11 September 2020: Really enjoyed the conversation with @jimabc_ today. Touched on juicy topics like coordinating across platform teams, when a shaped pitch is “shaped enough” for the team to work autonomously, scheduling junior team members, and when to do user research. https://www.youtube.com/watch?v=c_v_TLXNsqI
• 11 September 2020: What's your source for that?
• 11 September 2020: From today's Shape Up Livestream with Jim Matteson https://www.youtube.com/watch?v=c_v_TLXNsqI https://twitter.com/FrankTldr/status/1304517140486205446?s=20
• 11 September 2020: “Apple was this wonderful combination of top-down leadership and bottom-up contributions.” “Steve was very clear ... you knew what the vision was. ... But still it was just a vision. ... It was our job to figure out how to do it.” Link to clip: https://overcast.fm/+BlzFXZxkQ/15:42
• 11 September 2020: The original iPhone team had no product managers. Just programmers, designers, and executives. “It was all our responsibility to make sure the product was going to be great for people.” From a 2019 interview with Ken Kocienda. https://overcast.fm/+BlzFXZxkQ/31:29 pic.twitter.com/OE8bv2p8bl
• 11 September 2020: Going live in an hour. https://twitter.com/rjs/status/1303838195793059840
• 11 September 2020: All of it. The very pool of potential structure is immense.
• 11 September 2020: I can reply with a cliché, or I can reply with something novel. There's no hindrance.
• 11 September 2020: It's not so complicated. It's just richness. Like language. You have a bunch of words you can reach for that are already known. And still, new words and new constructions appear all the time.
• 11 September 2020: I always learn a lot from these sessions. It’s so interesting to hear the specific context someone is in, and try to answer specific questions I’ve never considered before. In this case I’m curious to what extent the world of iOS development is the same or different. https://twitter.com/rjs/status/1303838195793059840
• 10 September 2020: Our designer just got a proof and made some changes. Soon.
• 10 September 2020: Yes. The other important difference is the level of abstraction. The work is not specified down to the details. That enables fixed time variable scope.
• 10 September 2020: This question of purpose is absolutely central to the topic.
• 10 September 2020: Well said. https://twitter.com/ajmoralesguzman/status/1303860384726765573?s=20
• 9 September 2020: Livestream this Friday: I'm interviewing another Shape Up adopter and answering questions. My guest will be Jim Matteson, iOS Engineering Manager at CoffeeMeetsBagel. Tune in Friday at 1pm Mountain time. https://www.youtube.com/watch?v=c_v_TLXNsqI
• 9 September 2020: Misalignment is I’m getting more responses to tweets about JTBD (and DMs, emails) from people who haven’t done any interviews and haven’t put hours into understanding it than from those who have.
• 9 September 2020: What’s the book about?
• 9 September 2020: Delightfully pithy. https://twitter.com/dreinertsen/status/1303797250292817920
• 9 September 2020: It’s not easy but Twitter can occasionally enable a constructive dialectical process. https://twitter.com/normonics/status/1303791501412052996
• 9 September 2020: A deep and juicy question. Among lots of parallel spaces to draw from... language could be a good one. We can have an idea of what we want to say, but then constructing a sequence of words is something else. (Langacker’s semantic vs phonological poles may spark ideas.)
• 9 September 2020: Yeah I see the overloading more clearly now. Very interesting.
• 9 September 2020: My assumption (and this might be relevant here) is that we don’t just go to level 2 without something in mind at level 1. And in a healthy piecemeal adapation unfolding process, we revise 1 as we alternate with 2.
• 9 September 2020: That helps me reframe. I’m seeing two levels. 1) An imagination level, where both “context” and “prototype” exist abstractly. 2) A concrete level, full of details we can’t know until we interact with the reality. By up/down top/bottom I meant interaction between 1 and 2.
• 9 September 2020: Slippery recursive slope here. We can view a model/representation itself as a prototype. It doesn’t come from nowhere. Some situation brings it to mind as fit for the purpose. It’s just at higher abstraction, so big potential for misfit. Need to concretize piecemeal to check.
• 9 September 2020: Suspect “scientist” is hard to use as a designation because it’s static, not dynamic. People go into science from different starting points intending to reach different outcomes. For at least one of those paths, perceived lack of risk may be a requirement making it attractive.
• 9 September 2020: I disagree, but don’t know how to make the case, which is a super fun place to be. I’m inclined to map top-down to that which motivates us to find the latent center and constrains which of many latent centers is best suited. Going to think more about this.
• 9 September 2020: Maybe the villain is too many top-down decisions made at once. They conform to each other but not to the existing whole. Then piecemeal adaptaption is about alternating top-down and bottom-up to impose what we want (↓) in a way that’s harmonious with what is there (↑).
• 9 September 2020: Been thinking about this and suspecting top-down/bottom-up isn’t the issue. “We want a house to exist here” is top-down. Fitting the site into the local order (a la the “Site Repair” pattern) is bottom-up. Think these go together. The deeper issue is piecemeal adaptation.
• 9 September 2020: I think it's less known because it's more demanding.
• 9 September 2020: Trying to debug my JTBD tweets. Something is misaligned. If you've done more than reading articles about JTBD, and you've done 10+ interviews (timeline, forces), can you raise a hand? Let's see how many of us there are in this circle here.
• 9 September 2020: Check out the book Competing Against Luck for a good primer.
• 8 September 2020: It’s about getting them in and out of the car.
• 8 September 2020: This tweet assumes background with JTBD. The book “Competing Against Luck” is a good primer.
• 8 September 2020: It means you’re in a specific circumstance. My favorite example is the minivan. Some people say they’ll never buy a minivan. Then the third kid comes and boom. Suddenly they see it differently and make very different trade-offs.
• 8 September 2020: This is why “outcome” or “need” isn’t sufficient for design requirements. Desired outcome could be “make sure nothing slips through the cracks.” The context is totally different if they’re growing from 5 to 6 people or just shrunk from 5 to 2. They’ll make different trade-offs. https://twitter.com/rjs/status/1303455312100417537
• 8 September 2020: When someone tells us what is “wrong” with Basecamp or Shape Up or whatever ... they might very well be giving us important information. But first we have to check if they’re in the job or not. If they are in the wrong context, the trade-offs won’t align.
• 8 September 2020: The main thing that happens when someone moves “in the job” is they make new trade-offs. Suddenly things that were unacceptable before become alright or even valued. Canonical example: parents buying a minivan.
• 8 September 2020: A JTBD is like a wind current. First we find where the wind is blowing. Then, subsequently, when some people report misfit or reviewers don’t get it etc, we have to ask ourselves: are they “in the job” ? Big diff between us not doing the job versus them moving out of the job.
• 8 September 2020: Notability and GoodNotes are both “simple vector” sketchpads. You’ll also see recommendations for things like Paper by 53. Those are more for artists. Like a little book of watercolors. Not a good fit for technical / whiteboard type drawing.
• 8 September 2020: Many people recommend Concepts. For me, it’s much too complex. It’s 180° from “whiteboard.” GoodNotes is one step up in complexity from Notability if you want more parameters. A key feature of Notability for me is it’s very easy to erase or select w/ lasso to move things.
• 8 September 2020: If it’s just for you (not collaborative) Notability is my long-time fave. I’ve tried them all. Very few interface elements, just the right things. Less of a super-do-it-all creative tool and more of a distilled just-what-you-need thing.
• 8 September 2020: Great story by CTO @bensinclair on adopting Shape Up. https://bensinclair.co/2020/09/08/tithely-new-development-process/ pic.twitter.com/Jrk8haBzEH
• 7 September 2020: This clip is an amazing example of fixing a system by understanding the trajectory of its behavior. Steve Albini explains why a certain phase issue happens when recording sound from a bass guitar. https://overcast.fm/+Tas1EWrPA/1:18:37
• 7 September 2020: "We are now able to focus deeply on hard problems, take guilt-free time to rest and sharpen our skills, and regularly think long term about the direction of our work." https://ncphi.dev/blog/implementing-shape-up
• 7 September 2020: The Ergodicity Economics 2021 conference now offers an email signup list for people who want to attend as audience members. http://lml.org.uk/ee2021/
• 7 September 2020: Re: evidence: https://twitter.com/harrydcrane/status/1301140310123335681
• 6 September 2020: Interesting take on analog vs. digital recording in this interview w/ Steve Albini. In digital, you can change everything later. But people forget: there isn’t infinite time to use all that optionality afterward. Lesson: make more upfront decisions. https://overcast.fm/+Tas1EWrPA
• 5 September 2020: That symbol we always see on phone apps... the ☰ or the ••• ... We could borrow a word from Greek architecture for that. "Triglyph" — it means three marks. https://en.wikipedia.org/wiki/Triglyph
• 5 September 2020: A challenging point: Don't respect claims about likelihood/probability unless the proponent has meaningful downside for being wrong. Makes me wonder what this implies for different roles in a product org. https://twitter.com/HarryDCrane/status/1302345362905149442?s=20
• 5 September 2020: Experimenting with levels of scale on the project screen. pic.twitter.com/AUBfkiVZqU
• 5 September 2020: To my ear "following a sequence" implies using a predetermined sequence. Those only exist for things that have a lot of reps already (like a kitchen or a gate). I am taking it step by step to try and unfold it in the right sequence, with trial and error.
• 5 September 2020: Thanks. This is a mockup. I expect the font rendering to be different in the browser so I'm not trying to tune it much at this stage.
• 5 September 2020: It's a mockup.
• 5 September 2020: I'm trying to learn how to make something I like instead of making something that looks like it's "supposed" to look.
• 5 September 2020: Playing with an off-trend, less "clean and professional" approach to UI on this side project. Inspired by Christopher Alexander and Greg Bryant's Gatemaker. pic.twitter.com/eeUY2e25aV
• 5 September 2020: A good way to look at cost overruns. From @BentFlyvbjerg . pic.twitter.com/1i6KjA7Yka
• 5 September 2020: It’s the same. The output of shaping is a pitch. The pitch describes the shaped work for the betting table. If it gets bet on, it can be re-used to present the work to the build team for kickoff.
• 5 September 2020: For this split I would treat all the inputs to shaping (including research etc) as part of shaping.
• 5 September 2020: That belongs to shaping.
• 5 September 2020: Not an assumed competency. It’s an effect, not a cause. The right enabling structures (clear boundaries from shaped work, time box, method for capturing discovered tasks...) help people to self-organize.
• 5 September 2020: Betting table defines project teams. Re: performance, we have a manager of designers and a manager of programmers (both do hands-on design/programming themselves as well).
• 5 September 2020: Shaping is a kind of work, like programming. It requires dedicated time, different skill, specific inputs, etc. Just like programming, we don’t formally coach. But anybody who’s interested can learn from each other.
• 5 September 2020: First, it’s not a power thing. Figuring out what to do is work. It requires dedicated time, knowledge, different skills and inputs. Then, equally important, is defining the work at the right level of abstraction. We leave lots of room for the teams to determine the final form.
• 5 September 2020: Been testing out this split when talking to people and it seems to hold true. https://twitter.com/rjs/status/1302067841315741697
• 5 September 2020: @nurijanian @Suhail @jasonfried @dhh IMO many software teams would clarify their processes and communication by factoring out #1 and #2 as explicit responsibilities. There’s less misunderstanding when the betters and shapers are explicit instead of implicit. Clearer inputs and outputs and touchpoints for feedback.
• 5 September 2020: FWIW I think “Product Management” decomposes into some mix of these three: 1. Defining what the work is (shaping) 2. Choosing what work to do and when (betting) 3. Coordinating other peoples’ time/effort (managing) We don’t have PMs because our teams self-organize #3.
• 5 September 2020: Correct, we have no PMs. Product decisions (what to work on, when) are made at the top by @jasonfried (CEO) and @dhh (CTO), with input from others depending on the product and context. Jason’s the last word. I’m not a PM, I’m an input to them: I shape options to bet on.
• 4 September 2020: At the same time, time passes and we may feel that this project isn't the most important thing anymore at the next betting table. So it's not guaranteed a second pass either.
• 4 September 2020: Not exactly. I think of the circuit breaker firing because somethings as wrong with the work. So we don't re-invest in bad work or a solution that has problems. If someone had to drop out, it doesn't mean there was anything wrong with the work.
• 4 September 2020: Great observation. Lots of energy burning off as heat instead of light.
• 4 September 2020: Wow what a great story. And an optimistic picture for local news. https://twitter.com/awilkinson/status/1300823541709860865?s=20
• 4 September 2020: "The organisers welcome submissions of theoretical, empirical, and experimental research, and encourage especially contributions that are critical of Ergodicity Economics." This should be interesting. https://twitter.com/EE_2021/status/1301904773537501184?s=20
• 4 September 2020: We don’t try to mitigate that. It’s more efficient to take that hit from time to time than to try to prevent it from happening.
• 4 September 2020: I don’t know Katz or his work.
• 4 September 2020: Yeah a few people mentioned that now. Makes sense.
• 4 September 2020: Ulwick goes deep on the supply side and is good there. Doesn’t focus on the demand side.
• 3 September 2020: Super interesting. Suggests there's a precise way to define how "structural" some behavior or problem/non-problem is.
• 3 September 2020: Outcomes are effects, not causes. To cause things to happen, you have to define where people start. The initial conditions. Extremely important. What signal is coming in. What are the control factors in that specific circumstance. https://twitter.com/rjs/status/1301650895692730369?s=20
• 3 September 2020: My rough heuristic for filtering whether something that claims to be about "jobs to be done" is operable or not. https://twitter.com/rjs/status/1301650895692730369?s=20
• 3 September 2020: Competing Against Luck is a good primer. Super rough heuristic: if someone only talks about "outcomes" or "needs", they're missing it. Look for the pairing of context and outcome. Not just "to", but also "from." You need both for a causal model.
• 3 September 2020: It kicks the can. There's no filter on following either.
• 3 September 2020: If you bracket the ... what do you call it ... power space? ... and just deal with the actual options, then the time-average growth story is clear cut. When people question whether a more optimal flow should be available in the space, the debate moves somewhere complicated.
• 3 September 2020: I suspect there's something hairy underlying the debate that issues from this. Something about the configuration space of flows, and to what extent the question is about choices within the existing space vs the shape of that space.
• 3 September 2020: I didn't. It was a reflection from my own experience. It wasn't a design criteria: https://twitter.com/rjs/status/1301272377469235201?s=20
• 3 September 2020: The good and bad of Twitter: no cost to entering discussions. Means it's easy to get swept away or distracted by skimmers and verbalistic interpretations. No filter on how to earn in to the discussion. @nntaleb handles this by aggressively blocking. But that's not my style.
• 3 September 2020: You can't directly map a JTBD to the supply side of media buying. Nobody who sells you ads is going to have a checkbox that corresponds to your job. That's the point. You have to translate into demographics.
• 3 September 2020: NNG doesn't understand JTBD. Personas have their place. It's a question of when attribute-based segmentation is useful or not. JTBD is a different type of segmentation according to context and outcome. Orthogonal to attributes.
• 3 September 2020: The idea of a "view on a JTBD" isn't coherent. You're in the job or you're not. That's why I suggest checking back to first principles.
• 3 September 2020: Check out Competing Against Luck to learn about attribute vs situation-based segmentation.
• 3 September 2020: Sounds like you're not clear on what a job is. Competing Against Luck is a good start.
• 3 September 2020: Exactly. Use JTBD for design trade-offs (eg the content and messaging of the ad). Use attribute-based segmentation for the media buy (eg we think we're more likely to find people in the job if we target these attributes).
• 3 September 2020: "Innovation is conflict-based ... we need to have very different points of view in the room and we need to know how to argue ... We bring debate into the team. You tell me why we need to kill this, you tell me why we need to move forward." - @bmoesta https://overcast.fm/+RkNUybGs0
• 3 September 2020: Another example: Personas as a segmentation type are operable with buying media (ads), but aren't operable with making product dev decisions. Vice versa for JTBD. https://twitter.com/rjs/status/1301298435190972416?s=20
• 3 September 2020: Sort of a 90s web design vibe here on the BBC’s Rethink site ( https://www.bbc.co.uk/programmes/p08kq9ck ) Color blocks and the old “site in a box” approach. I like it. pic.twitter.com/g4aUtDjV2F
• 3 September 2020: Ok maybe it's just me :)
• 3 September 2020: No plans for roadmapping features in BC4. Roadmapping has been on my mind because many people who read Shape Up are asking about it, and I’m in the middle of designing a portfolio of options for BC4.
• 2 September 2020: In other words, viewing something as a different kind of thing embeds it in a different network of functionality.
• 2 September 2020: Had a first inkling about why non-mathematicians might get excited about category theory or homotopy type theory... Take roadmaps. When you recast a roadmap as a portfolio of options instead of commitments, those become operable w/ new actions/processes and inoperable w/ others.
• 2 September 2020: I'm talking about the specific flow someone is in when they use the Focus & Reply feature on HEY. Not about replying to email in general.
• 2 September 2020: Btw none of these things were intentional in v1. The team just stripped it back as much as possible to make the flow more focused. But now, seeing that the date isn't there, I'm calling out that out as a feature, not a bug.
• 2 September 2020: Hard to make the case that the date meaningfully helps someone make progress getting through their stack of Reply Laters. Easy to feel, when you use it, that the date gives a bad smell and makes you feel worse about what you're doing.
• 2 September 2020: What's not there can be as important to a feature as what is there. https://twitter.com/rjs/status/1301269180067446785?s=20
• 2 September 2020: Consistency alone is never a good design principle. HEY's Reply Focus mode doesn't show dates on emails. That's inconsistent! By default, a designer could easily say "of course a date should be there!" But in this context, dates signal an email is old and make you feel bad.
• 1 September 2020: A lot of conflicts about where “design” belongs in the org stem from lack of clarity about what the role means. It’s not one role. Eg. typography obviously doesn’t belong at the top. Need to spell out which aspect of design belongs higher, and what the inputs and outputs are.
• 1 September 2020: At Basecamp, “shaping” is upstream from both design (UI/UX) and programming. Inside a project, design and programming are on equal footing. They work together to implement the shaped work. See Ch 11 of Shape Up for how they do that. https://basecamp.com/shapeup/3.2-chapter-11
• 1 September 2020: I look at it in terms of what you want to constrain what. If you want the back-end to constrain the front-end, then front-end can be downstream from back-end. If you want interaction to drive trade-offs, then UI design should be upstream from the programming decisions.
• 1 September 2020: First thing I would do is break “design” down into separate activities. Shaping the project and styling a button are both “design” activities, but they happen at different stages of the project by people with different skills under different constraints.
• 1 September 2020: Acknowledge
• 1 September 2020: Lots to like about this demo by Panos Panay. Unscripted, real. Less corporate “Apple Event”, more QVC. Re: the UI, he repeats “keeping you in flow.” I hadn’t thought before about often we get jumped away and disconnected from what were doing on a phone. https://www.youtube.com/watch?v=R1CNwBzYqRs&feature=youtu.be&t=490
• 1 September 2020: With our head of support, or our data analyst, or one of our senior programmers, lead designer, etc. For example I had a 1:1 with our data analyst a month ago, with no agenda. It sparked a whole new research idea for BC4 that was really fruitful.
• 1 September 2020: Artifacts are easy to copy. Point of view is not.
• 1 September 2020: The best moat is a different point of view.
• 31 August 2020: ( https://basecamp.com/shapeup/3.1-chapter-10#imagined-vs-discovered-tasks )
• 31 August 2020: Why Jira works for imagined tasks, not discovered tasks. https://discourse.learnshapeup.com/t/shapeup-in-jira/514/9 pic.twitter.com/SOWs9qYm7d
• 31 August 2020: Relevant Shape Up chapter: https://basecamp.com/shapeup/3.3-chapter-12 pic.twitter.com/qmOX4soYhX
• 31 August 2020: Example of mapping scopes analytically. (Pictures what we do intuitively.) 1. Draw interrelationship diagram (key pieces go around a circle, arrows show which things enable other things) 2. Segment parts that are more interrelated than others 3. Name them (See Shape Up Ch 12) pic.twitter.com/h35qf2vuR9
• 31 August 2020: (I don't think this visualization has any practical use. Just trying to clarify the mental image.)
• 31 August 2020: Just made this an example. The outer ring are things that have to be there. They specify both back-end and front-end requirements. Inside a million smaller things need to be worked out that are constrained by the main things. pic.twitter.com/bk4gK3X87F
• 31 August 2020: Shaping > Filling is a different way of thinking than Design > Build. Why? You design and build at every stage. (See Kauffman’s work-constraint cycles. A cannon does work on the cannonball but it also takes work to make the cannon.) https://twitter.com/rjs/status/1300541878517903360?s=20
• 31 August 2020: In the concentric circle approach, we can mix elements from different layers together in a ring. For example, a concept has a few requirements in the model and in the UI on the outside that should constrain all other decisions inside. That’s what shaping is about.
• 31 August 2020: Many of us learned to picture software as a stack. For design purposes, it’s often better to think in concentric circles instead of layers. Why? Because there’s a huge difference between a UI decision that constrains the backend vs a backend decision that constrains a UI.
• 31 August 2020: I don’t need to mechanically cluster these. It’s an interview screener. I expect only ~100 responses. Other questions will eliminate a bunch and I’ll end up reviewing around 20-30 manually one by one.
• 31 August 2020: For JTBD interviews the key thing is determining if they were the decision maker or not and whether they bought in the right window of time. Then beyond that some domain-specific questions can ensure covering a greater variety of cases (role, size of team, industry, etc).
• 31 August 2020: Greg describes the program in that conversation.
• 31 August 2020: This? https://youtu.be/X-5KG73fzJ4
• 31 August 2020: A small building. Described in Ep 10: https://synthetic.transistor.fm/episodes/feeling-form-and-function
• 31 August 2020: Synthetic A Priori is on hold while I do some learning and building. I’ve been applying Alexander’s process to both a physical building project and a software side project in parallel. Time to learn more than time to talk. Hope to have some more stuff to share before long.
• 28 August 2020: That's an invitation for anyone of us who are interested to figure it out.
• 28 August 2020: This is exciting. A set of user interface design patterns Christopher Alexander defined as a result of working on the Gatemaker project back in 97. These especially stood out: - Balanced Windows - Settled Workspace - Description vs. Instruction https://www.gregbryant.com/grogbrat/aspen97/TOJOY.html
• 28 August 2020: Of course, the world looks different when your costs are under control and you have a long runway vs. if you are sinking and need to hit numbers to survive. But I don’t believe the fundamental approach changes. We need a theory of what matters demand-side and shaped options.
• 28 August 2020: My BC4 “portfolio” of projects to potentially do is a mix of things that plug holes (downside protection) and things that could possibly bring in lots of new usage (convexity).
• 28 August 2020: Then regarding general direction, they want to dedicate time to build BC4 next year. Within that broad frame, I’ve worked out a definition of what matters on the demand side and project ideas on the supply side.
• 28 August 2020: Haven’t written about that. Jason and David never set target metrics — they’ve always focused on controlling cost and downside. The key thing about strategy is staying alive tomorrow to play again.
• 28 August 2020: Not specifically in this one. There are so many things to talk about.
• 28 August 2020: Thinking of ergodicity in other fields reminded me of this by Peter Molenaar. https://www.jstor.org/stable/20696008?seq=1#metadata_info_tab_contents pic.twitter.com/lHndSRNvKA
• 28 August 2020: It's a specific research project, targeting certain people who cancelled their Basecamp accounts and switched to using something else.
• 28 August 2020: New podcast interview. @stubalcombe asked me questions about research, job-to-be-done interviews, shaping, and sharing demand-side knowledge with the team. https://www.learnwhy.co/customer-conversations/shaping-strategy-with-basecamps-ryan-singer
• 28 August 2020: Sent out a survey today to recruit interview subjects. Instead of a standard "Industry" dropdown, I asked this. Much more informative responses. pic.twitter.com/BbWcQQxmJN
• 27 August 2020: At Basecamp: “Yeah 10am Tuesday works. I’ll see you then.” We put it on our private calendars and meet at the agreed time. Dealing with the outside world, I often get multiple emails for a single meeting. One from Zoom, usually two+ Google invitations. This is not necessary!
• 27 August 2020: Fixed time, variable scope. From Alexander’s “Battle.” pic.twitter.com/qjd5o3cqaG
• 27 August 2020: Maybe the challenge/opportunity there is to articulate your gut feeling. What does that struggle mean in terms of a risk or payoff to the org on second and third orders. And contrast to the other top two. You can call this “sizing” the job.
• 27 August 2020: Sounds complicated.
• 27 August 2020: Important for product managers. One way to get out of the weeds is to call the weeds weeds. https://twitter.com/rjs/status/1298799746497122305
• 27 August 2020: Always treat the struggle to prioritize many things as a smell that none of them are important. If something was really important, you would just do it next.
• 27 August 2020: Instead of prioritizing, I prefer the “slam dunk” test. Binary. Which of these things are obvious no-brainers to address? If none of them, then it may point to problems in your interviewing (more likely) or lack of struggle/interest in the area you’re in (possible).
• 27 August 2020: One more connection. The two may overlap in Alexander’s “Site Repair” pattern from A Pattern Language. The notion is to start your project in a place where things are already lacking or not working.
• 27 August 2020: They’re in his book “Battle.” It’s an end-to-end case study of designing and building the Eishin School in Japan.
• 27 August 2020: Other people have other definitions. In my world, JTBD is always a push to a pull. There’s no demand to change if everything as is is fine. And there’s no change if there’s nowhere new to go. So you need both.
• 27 August 2020: Eg. I learned that people buy Basecamp to stop information from slipping through the cracks between people. Then, I noticed people asking each other to do things in Pings, and there was no way to track and follow through. Jumped high on the list for BC4.
• 27 August 2020: In my experience the JTBD hits you over the head with ideas at first, but only when it’s crispy (concrete, detailed). If it’s is too high it doesn’t do anything. Longer term, the JTBD—again, when crispy—acts as a filter on ideas to help judge if people will value them or not.
• 27 August 2020: It may be possible that the JTBD sets the survival criteria. “If you do x, y, z you will scratch the itch.” But that’s more like a lower bound. Maybe it’s very hard to define where the upper bound is. Clay’s comment here is relevant: https://twitter.com/rjs/status/1287956059974377474
• 27 August 2020: I disagree. I think “what to build” has multiple levels to it, including the outer wall of constraints. Those constraints have a huge influence on what we make. So far I’m thinking they come from the JTBD.
• 27 August 2020: This would mean a pain point, difficulty, struggle, or dissatisfaction pushes us to start a project (instead of just going on as before). Then we get to shape the project, and to say to ourselves: “This is worth improving. Now, what’s the best, most alive thing I can create?”
• 27 August 2020: That is, the JTBD approach might be good for “site selection” in the space of constraints. The outermost wall of what we’re doing. But to define positively what goes into that space and bring out the most potential within those constraints may involve some dreaming.
• 27 August 2020: I suspect the latter might be downstream from the former: The decision to undertake the design and construction of a new campus — and to budget for it — might best be understood through struggle and JTBD. But then the way to realize that positively may be through vision.
• 27 August 2020: Chewing hard on this... A product design process, esp with JTBD interviews, starts with struggle, to define value and position in a market. Alexander’s interviews (eg. in “Battle”) are about hopes and dreams, to envision an ideal. Questioning how to sequence & relate these.
• 27 August 2020: Design inspiration from Christopher Alexander’s “Battle.” “This is a tapestry of space and stone.” pic.twitter.com/stg4nHlBvZ
• 26 August 2020: Think of the pitch as a potential bet. You can clarify the appetite so it's not just time but also # of people.
• 26 August 2020: The print edition is the same as the online one. I think you’re asking about how to break work into separate scopes (Ch 12). It’s a bit of an art to find orthogonality. @bmoesta has a tool called the interrelationship diagram to do it but neither of us has written about it yet.
• 26 August 2020: The marketer in me can't resist: he could accurately title this "Calculus Without Limits."
• 25 August 2020: The book doesn’t translate straight to audio because of the way the illustrations are woven in. Playing with an idea to talk through the main points of each chapter as a podcast series instead.
• 25 August 2020: The print edition is coming soon. Here’s the jacket design. pic.twitter.com/p75JwT0j01
• 25 August 2020: 1 week works. It’s a little tight—not much time for heartbeats or coordinating the next cycle. For us 3 weeks would feel too long. Like we were sitting on our hands. But feel free of course to experiment to find what works in your circumstance.
• 25 August 2020: Christopher Alexander on NPR in 2005: "We are beset by images, instructions, notions of what is fashionable. . . . the most important thing that you must do is to get rid of those voices ... only pay attention to whether you are actually feeling better." https://www.npr.org/templates/story/story.php?storyId=4469331 pic.twitter.com/H9LiQ75Xqd
• 25 August 2020: Christopher Alexander on NPR in 2005: "We are best by images, instructions, notions of what is fashionable. . . . the most important thing that you must do is to get rid of those voices ... only pay attention to whether you are actually feeling better." https://www.npr.org/templates/story/story.php?storyId=4469331 pic.twitter.com/lEATEHk4Nk
• 25 August 2020: Folks who need to sell but don't want to be salespeople should check this out. If you run a podcast for software entrepreneurs or freelancers, @bmoesta would be a great guest. https://twitter.com/bmoesta/status/1297949936504508416?s=20
• 24 August 2020: If you feel like new incoming requests can't wait six weeks, that could either be a culture problem or a legitimate requirement from your business model. A genuine product company can wait 6 weeks for anything. But if you service a few big-paying clients, maybe not. Check that.
• 24 August 2020: If you can't do that, that's a structural issue to look into. If you can, then what you put into that bet is up to you. It can be "reactive" if you want it to be. The point is to be intentional about it and know where you're going over the next six weeks, not wandering around.
• 24 August 2020: The key point of Shape Up from a management perspective is making bets. To bet six weeks on something, you have to own the time of that team that you're betting. So that's the first question: If you wanted to, could you put these 3 people on X for 6 weeks?
• 24 August 2020: Decline isn’t a real option. More about acknowledging and filing. Eg when a customer sends a feature request, you don’t say “no.” You say “thank you”, clarify as needed, and file in the back of mind in case it becomes relevant later.
• 24 August 2020: Long lists or backlogs aren’t inherently bad. What makes them bad is the feeling of guilt when you see all these issues you couldn’t solve or fix, and you know there will never be time for them.
• 24 August 2020: It’s unbelievable how often the word “guilt” comes up when talking to people who do issue-based, reactive work. There’s more work than time, the work comes from other people, and it’s hard to ignore it, delete it, or say ‘no.’ https://twitter.com/rjs/status/1298034157663080449
• 24 August 2020: WIP on a “request flow” feature for BC4, alternative to To-Dos. Two struggles: 1) Social awkwardness of adding work for others. Assigning is wrong. Need to “ask” not “task.” 2) Guilt. Someone adds a task you’re unlikelty to do. You don’t want to delete. Sits around, piles up.
• 24 August 2020: IMO the important thing is to be clear about why people are buying the current version. That very growth you talk about is license to not listen to people and set your own direction. We’ve done this with BC for years & continue to set our own course instead of being reactive.
• 24 August 2020: Promising stuff does create that pressure. It’s very rare. In 17+ years I’ve only seen Jason and David do that a couple times. We are in our best shape when we don’t have any public commitments. We’ll be back in that zone again very soon.
• 24 August 2020: I know of one Fortune 50 company that uses it across their core digital teams. It wasn’t a big jump. The main thing is allocating time for people to do spiking work in the shaping phase instead just building against tickets.
• 24 August 2020: Of course. I’m not saying anything about what is understandable. That totally depends on the context and the effort the person makes to learn also. The point is that understandability is not some different thing from functionality.
• 24 August 2020: Probably have to ask why things are less calm. - A temporary storm after a launch? (HEY) - Biz model mismatch (you think you're making "one" product but sales keeps promising custom features...) - Growth of customer base means more issues in absolute numbers and too few people?
• 24 August 2020: They're the same thing. If it's not understandable then it doesn't work functionally.
• 24 August 2020: Back next week. https://twitter.com/rjs/status/1297728197270806528
• 24 August 2020: Synthetic A Priori is taking the weekend off. Back next week. (For listeners of Episode 10: We broke ground on the barn project. I was too busy digging post holes to do an episode.)
• 23 August 2020: Challenging thought for our circles here: Innovative products make up a small subset of the potential good things a person can make. Product development is a fruitful place to learn about and do design. But for design in the broadest consideration, it’s overconstrained.
• 23 August 2020: Actual innovation in education taking place. So many good things here. https://twitter.com/robertghrist/status/1288218327127666690
• 21 August 2020: Going live now https://twitter.com/rjs/status/1295790859359682561?s=20
• 21 August 2020: Tomorrow https://twitter.com/rjs/status/1295790859359682561?s=20
• 20 August 2020: It's definitely worth learning what an option in finance is and looking at all the many ways in every day life that it applies. Extremely useful broadly applicable concept.
• 20 August 2020: Convexity is where you have a bigger upside than downside, and the downside is certain and the upside is uncertain.
• 20 August 2020: "We" is accurate when it reflects a question posed to multiple people and they as a bloc agreed.
• 20 August 2020: The foundation for convexity is reserved capacity. I couldn't pursue this unexpected, incredibly insightful conversation that just happened if I had meetings all day. But this one conversation might change a core feature of BC4. The known downside is the cost of reserved time.
• 20 August 2020: "Worth the pain of memorization" — yes I think this is actually part of the job. Knowing the system. Aka "domain knowledge."
• 20 August 2020: Another way to think about this: when the data blurs agents together, you lose longitudinality. It's the equivalent of averaging out.
• 20 August 2020: Consider that a special case, where making that substitution doesn't corrupt the longitudinal data. Saying "we" when there were different decision makers at different points crosses the wires and destroys the data.
• 20 August 2020: "We" is good for celebrating. And it's very good for goal-setting. Do things good for all of us and enjoy the fruits together. But it's not good for explaining, teaching, debriefing or otherwise understanding cause-effect.
• 20 August 2020: Tip, the next time you tell the story of a project or a decision, don't say "we." Try to actually identify who contributed which aspect. It increases everyone's understanding of the actual truth of how things happen.
• 20 August 2020: No. The "real" challenge is actually understanding what you are doing, yourself. Sharing information is trivially easy — you just sit together and talk.
• 20 August 2020: Since everything we do has side effects, one of our first tasks as designers is to understand how things are connected.
• 19 August 2020: These are the kinds of little stupid struggles people have every day, while the industry talks about Machine Learning and AI. There is a massive opportunity and low hanging fruit for fundamental basic product design in software. https://twitter.com/rjs/status/1296206145422409729?s=20
• 19 August 2020: This "chronological sheets of content" thing is a powerful underused pattern. You just hit +N and get a new fresh one. And you never have to wonder how to find something you did recently.
• 19 August 2020: Why the right turn? When the Save dialog appeared, I asked what I would call it and where it would go. Probably on my Desktop, which is full of files. How will I find it tomorrow? If I drop it in Notes, I know I can get back to it chronologically. Plus, I don't have to name it.
• 19 August 2020: Example of interesting "little hire" behaviors that can lead to product strategy ideas: I popped open a TextEdit document. Wrote stuff in it. Decided to delay the project until tomorrow. Hit "Save." Saw the Save dialog. Hesitated. Hit Cancel. Select All. Copy. Pasted into Notes.
• 19 August 2020: Same content.
• 19 August 2020: Some great Shape Up testimonials are coming in. Add yours for the print edition here: https://www.surveymonkey.com/r/Y6LKMM8 pic.twitter.com/Ee74fM5tUN
• 19 August 2020: Soon.
• 19 August 2020: Has Shape Up helped your team? I'm looking for testimonials for the back cover of the print edition. Would you be willing to write 1-2 sentences about how Shape Up made a difference? You can submit here: https://www.surveymonkey.com/r/Y6LKMM8 Thank you!
• 19 August 2020: I’m thinking of it more like these are the functions that have to happen to do the job. Like a car ... certain things have to be there to transfer energy from the engine to the transmission to the wheels.
• 19 August 2020: Learned about Petri nets yesterday. Very close to breadboards but more general: places, transitions, and connections. https://en.wikipedia.org/wiki/Petri_net
• 18 August 2020: It's my experience through trial and error. Using these categories is working for me and matching what I see in the wild. That's what I mean by empirical. Based on experience, not theory or logical argument.
• 18 August 2020: I don't find that to be constructive at all. Anybody can say to someone else "you should do more." Not helpful.
• 18 August 2020: OmniGraffle.
• 18 August 2020: In other words, if you think you have a better scheme or segmentation, put it out there.
• 18 August 2020: It's empirical in the sense that if you find something that gets transformed that doesn't fall under functional, emotional or social, then you can put that on the table and say "I think this is an anomaly."
• 18 August 2020: I don't consider them motivations. They are different kinds of things to change. More like substances. There's a difference between changing the way I feel versus changing the direction of motion of the car versus changing the way people perceive me.
• 18 August 2020: What do you think?
• 18 August 2020: I don't believe anything about preferences because they are attributes, not dynamics. That's why I use JTBD. It's about circumstances and outcomes, not preferences.
• 18 August 2020: It's empirical.
• 18 August 2020: The "rooms in a house" picture works further downstream, when you have mechanical parts designed. Upstream, it's more like a network of relationships that could be resolved in a variety of different ways.
• 18 August 2020: (And sometimes getting stuck and bailing. Or jumping ahead to a supply side idea, then stepping back, etc.)
• 18 August 2020: There's no "one step" wherever everything gets specified. It's more of an unfolding process from the demand end to the supply end, gradually working out the form.
• 18 August 2020: Then looking closer at S2•S4, it'll unpack into separate systems again .. eg the thing that adds a new item is different from the thing that displays the collection of items already added. It's an unfolding process of figuring out what the actual subsystems are in the end.
• 18 August 2020: Kind of arcane. Means subsystem but intent is to define functions the overall system will do. Re: scope, some of these will be overlapping and resolved by one scope of work. Eg S4 capturing a new thing and S2 tracking something you just did are probably one system S2•S4.
• 18 August 2020: Big hire interviews from years ago set the broad frame. Then anecdotal stories about workarounds came up that I didn't understand. Years of convexity to anomalies (investing small amount of time to learn about odd behaviors). Then a surprise a-ha while researching something else.
• 18 August 2020: It was a combination of many things. Would require a full write-up to explain the backstory.
• 18 August 2020: I have never in my life looked at a utility curve and felt that it helped me understand anything.
• 18 August 2020: I did interviews to figure what they did today and what the causality (intent and outcome) was behind those things. Then I extracted these functions from the patterns.
• 18 August 2020: I'm not sure it's implementable as a real map, because we don't actual have metrics to define the space of possibilities. But as a loose intuitive picture I find it helpful.
• 18 August 2020: Yes.
• 18 August 2020: Emotional functions aren't about making the error message say "Sorry!" or using a happier color. They're about transforming an input energy to an output energy. Eg in S2: Before: "I felt anxious that I hadn't accomplished anything." After: "I felt I could allow myself to relax."
• 18 August 2020: All of those (Sᵢ) are functions. But some of those functions perform emotional or social transformations, not purely functional transformations. These three types of transformations are a key element of jobs to be done theory.
• 18 August 2020: Requirements aren't all purely functional. Some ("S2 — Track something I did that I didn’t plan to do") are emotional (= feel I did something). Others (S5.1 — Signal this is private) are social. Social, emotional are as important as functional reqs. https://twitter.com/rjs/status/1295820553857585152?s=20
• 18 August 2020: These main systems came from interviewing people at Basecamp and looking over their shoulders (digitally) at how they manage their private tasks today.
• 18 August 2020: This is not a feature request thread.
• 18 August 2020: Something I'm learning about shaping: trying to be "comprehensive" too early can kill momentum. First focus on things that differentiate and make this thing do the unique thing it does. Later fill in with all the necessary subsystems (eg "delete a task"). https://twitter.com/rjs/status/1295820553857585152?s=20
• 18 August 2020: Shaping the MY PLACE feature by spelling out the key functions it has to perform. pic.twitter.com/M7lzAObFkv
• 18 August 2020: Excited to announce a livestream Friday at 11:30am MDT with @greg_bryant , a collaborator of Christopher Alexander’s. We’ll talk about going beyond implementation patterns and applying Alexander’s principles on the front end to make software more alive. https://youtu.be/X-5KG73fzJ4
• 18 August 2020: Hill charts as implemented in Basecamp are better for project work, where the project has a clear end and the tasks are all related to each other. The hill chart + to-do list model doesn’t’ work for dealing with a never-ending flow of reactive work.
• 18 August 2020: Not planning that, no.
• 18 August 2020: Excellent thread. https://twitter.com/wittyusername30/status/1295511090021924865
• 18 August 2020: Erring on the side of oversharing. BC4 strategy work in progress. Idea is to start dev next year. NO BETS MADE. Only options. Could all change tomorrow. pic.twitter.com/93rCKJDeFu
• 18 August 2020: What do you think?
• 17 August 2020: That the car is broken is a problem. Demand is how someone defines for themself what needs to change and what shouldn’t change and —crucially—when and when not. This sets the bounds for a solution.
• 17 August 2020: Demand/Supply vs Problem/Solution: Demand is a problem framed as a process through time instead of a static fact or question.
• 17 August 2020: You can work on the same problem with different solutions, different problems with the same apparent solution, different problems with different solutions etc.
• 17 August 2020: Maybe fruitful: Applying Christensen’s modularity and interdependence within, not just across, firms. Means thinking of outsourcing/insourcing in our own systems. Eg. when to use the proprietary part we already have instead of inventing a new one. Code abstraction is like this.
• 17 August 2020: Clay Christensen’s theory of modularity and interdependence is a good lens for that. Effectively: “what do we outsource?”
• 17 August 2020: This also applies across categories. For example, there are things people do in other products or media to compensate for holes in Basecamp. We can choose to view that as a symbiotic relationship, or we can say that’s something Basecamp should be doing.
• 17 August 2020: This frames a way to think about markets and competition. Some products fit over the same island. Some have overlapping islands. Some have distinct non-overlapping islands. These relationships change over time. Applies to both supply & demand side.
• 17 August 2020: If you think of your product as islands in the space of possible functionality, customer requests are all about the coastlines. They suggest improvements on the edges of what already exists. Product strategy is also about starting new islands. Sometimes called “whitespace.”
• 17 August 2020: Love the “101.” Pretty sure it means there was a lot more where this came from and @bmoesta needed a way to stop. https://twitter.com/bmoesta/status/1295445729352318977
• 17 August 2020: This is as much about how people shop, decide, and buy as it is about how to sell (most of the latter reduces to the former). A must-read. https://twitter.com/bmoesta/status/1295445729352318977
• 17 August 2020: This is as much about how people shop, decide and buy than it is about how to sell (most of the latter reduces to the former). A must-read. https://twitter.com/bmoesta/status/1295445729352318977
• 17 August 2020: *case study
• 17 August 2020: His book “Battle” is an excellent care study. They laid out the whole campus by placing flags on stakes in the site. Then measured and drew where they put the flags to get to the drawing.
• 16 August 2020: ⭐️ Synthetic A Priori: Episode 10 What I learned using Christopher Alexander's methods on a real building project. "Feeling." Being in a space and judging a drawing are completely different. The surprise when better feeling leads to better function. https://synthetic.transistor.fm/episodes/feeling-form-and-function
• 16 August 2020: We used what we had: palettes, cinder blocks, an old door, ... pic.twitter.com/Vqv9iXriUB
• 16 August 2020: We didn’t define a formal sequence up front, but we (a small group) naturally defined a sequence as we went. It was amazing to see the ripple effects across the sequence. Making the main room the right dimensions suddenly created a better place for the bathroom, etc.
• 16 August 2020: A friend started the traditional way with a CAD drawing. Talked with him and extracted all the implicit patterns from the drawing. Kept the relationships between the main centers that he had worked out very well. Then shaped the spaces to figure out the “real” configuration.
• 16 August 2020: It wasn’t just aesthetic. Moving a bathroom out of the wrong place, around a corner, suddenly improved flow through a hall. Shifting an interior door six feet, to where it “felt right”, created a transition space for shoes and a bench. Form and function aren’t different things.
• 16 August 2020: Also amazed by relationships between centers. We moved a door (dragged wooden palettes through dirt and propped them on cinder blocks). Moving the interior door suddenly created a new lovely stretch of space between the exterior entrance and the door. Everyone: “oh I love that!”
• 16 August 2020: The tolerances are smaller than I expected too. Moving one wall just three feet completely removed the anxious/squirrely feeling from being too narrow. Everyone in the group sighed in relief when the wall was in just the right place. “Ok now this is comfortable.”
• 16 August 2020: One surprising experience... when the room shape was too small, I didn’t want to stay there: felt squirrely and wanted to get out. When it was too big, felt lonely with “dead” space on one side. The actual shape tickles the brain and triggers a whole range of emotional responses.
• 16 August 2020: Now I understand why the folks behind the @_buildingbeauty software initiative want people to do actual building projects. It gives you a deeper in-the-gut and in-the-chest experience of the concepts. Then you can port then back to other types of design problems. https://twitter.com/rjs/status/1295110836944433152
• 16 August 2020: Big experience this weekend: Got to apply Christopher Alexander’s methods to a real building project. Mocked on site, felt it / changed until it was right, then measured and drew it. The big shift was when we stopped talking and started moving things around and feeling it.
• 16 August 2020: Yeah we did a sizing project a couple years ago. Put a survey into the onboarding flow that slotted people into a job. The survey was 2 or 3 questions based on pushes and pulls. We were able to see how many people were in which job and how conversion correlated.
• 16 August 2020: Yes.
• 15 August 2020: I avoid trying to convince anyone of anything. https://twitter.com/rjs/status/1294500366956949504?s=20
• 15 August 2020: Shaping is either solo or a very small closed-door session with 1-2 people you trust that have shared context.
• 15 August 2020: I don’t understand the question. We came up with the idea together over a Zoom call.
• 15 August 2020: Not fast enough to update. A tool like that required manually copying a dot, positioning the label, setting the color, double-clicking to change the label text, etc.
• 15 August 2020: That is, the way to build shared models is to have shared experiences. I can’t do customer interviews and then really pass that on to anybody else. If they join some interviews, and hear it themselves, then they can build the intuition too.
• 15 August 2020: (I mean intuitive models, not just some formal thing.)
• 15 August 2020: I don’t think you can, even with artifacts. People build models through having experiences.
• 15 August 2020: I’m a fan of his talks and his thinking.
• 14 August 2020: On second order that builds up credibility. But the first order is where the magic happens.
• 14 August 2020: I don't want to convince anybody of anything. I want to give them things that work. They judge for themselves if it works.
• 14 August 2020: "Think of this as uncertainty about the work, not the team. I’m checking in because I don’t trust the work. I don’t trust it’s defined properly, scoped properly, or that we understood it fully when we decided to do it." https://discourse.learnshapeup.com/t/answering-questions-about-hill-charts/491
• 14 August 2020: Another one is designing the sequence of which things to prototype in what order and how far to go at a given time.
• 14 August 2020: Q: Am I doing something wrong if I have scopes on the hill chart with no to-dos? A: If you're doing that, you've achieved the first level of hill zen. Plus more Q&A on hill charts here: https://discourse.learnshapeup.com/t/answering-questions-about-hill-charts/491
• 14 August 2020: That's an "insider" aspect to Shape Up. Glad to hear that it clicked.
• 14 August 2020: Once we understand better how to frame and position it, and who to show it to and who not to show it to, we can make a clearer path to it and better explanation around it. That's starting to happen now.
• 14 August 2020: Another case of preserving optionality. I'd rather have a known downside (many won't discover it) than an unknown downside (people will stumble on it or get confused). We maintain expose to upside because knowledge of how to use it can spread by word of mouth.
• 14 August 2020: In other words, I'd rather run around with a well-tuned intuition for whatever data is about to come next than to drag suitcases of binders behind me to consult.
• 14 August 2020: Sometimes people doing research get bogged down by trying to capture, hold and organize all the artifacts. A lighterweight approach is to hold on to the model and forget the artifacts. When they confirm the model, drop them. When they conflict, change the model ...and drop them.
• 14 August 2020: This other case shows when prototyping changes the concept: https://twitter.com/rjs/status/1294382181477801984?s=20
• 14 August 2020: pic.twitter.com/ySEp6jYrQs
• 14 August 2020: The prototype substantially changed the shaped concept. Originally, I thought naming the piles could be a later step. First pile, then give the pile a name. Using the jig with a real problem, I found myself moving things between piles as I tried to name them. = New requirement.
• 14 August 2020: Exactly. This is what fixed time variable scope is all about. There’s “some version” of the idea that scratches the itch given the constraints.
• 14 August 2020: In this case the prototype didn’t change the concept. Just proved that it was actually useful in practice and that people were willing to follow through with updating it. Much cheaper way to learn that.
• 14 August 2020: Hacked it. The chart is drawn from a table, format of which is [X, Y, bubble size] for each element on the chart. The curve is the same as the bubbles, I just set the bubble size so small it looks like a dot. Functions in the F(X) columns turn the X values into the curve. pic.twitter.com/rllawQdVfC
• 14 August 2020: They are standard process for our Core Product teams that build features on our web apps.
• 14 August 2020: Another example of prototyping during shaping. Before we built the Hill Chart feature in Basecamp, I made this prototype in Numbers. We used it on a real project and posted screenshots to the daily check-ins. This gave us enough confidence to build the app version later. pic.twitter.com/1mixKP9uoT
• 14 August 2020: Nothing to read, but I did talk through the process in this podcast episode: https://synthetic.transistor.fm/episodes/iterating-the-form-context-boundary
• 14 August 2020: For the jig, I first took a screenshot of the existing (fairly raw) app for realistic proportions. Then added boxes for the “deck”, “hand”, and “piles” and locked that layer. Then I could drag cards around on top in a new layer, to pretend I was in the app.
• 14 August 2020: Part of shaping this was spiking a prototype. I made a jig in OmniGraffle and put a bunch of real data in. I didn’t have fresh interview data, so instead I tried affinitizing work I did in the last cycle to summarize into a Heartbeat post. pic.twitter.com/BXv3x9kiSr
• 14 August 2020: From a side project. Shaped a UI for doing the “affinitize” step of JTBD analysis. Could turn into a general-purpose affinitizing tool. Useful whenever you have a big pile of things and you need to reduce and abstract them to a smaller set of similar things. pic.twitter.com/OM24HEJh2r
• 14 August 2020: “Chronological connectivity” — what a nice phrase. It captures the shared spirit behind things like JTBD, Ergodicity Economics, and Alexander’s emphasis on sequence in design. Analogous to longitudinal thinking and—more fundamentally—the very notion of cause and effect. https://twitter.com/wrathofgnon/status/1022013821089660934
• 14 August 2020: Updated today's Shape Up livestream with timestamps for the major questions and answers. https://www.youtube.com/watch?v=EOQjCn4-9XY pic.twitter.com/i9fojluIOF
• 14 August 2020: That's ok. Whatever stack you're on, the important thing is to be strategic about the big efforts you tackle, instead of just wading into the weeds and getting lost.
• 14 August 2020: Basically you should not have any big unknowns in the cycle work. The whole idea of shaping is eliminating the major unknowns and leaving room for the team to work out all the many many small unknowns. Special, rare case is a pure R&D project but we do those very rarely.
• 14 August 2020: Got into some juicy questions about applying Shape Up with very limited designer hours in the second half of this conversation with @ppintoz . https://www.youtube.com/watch?v=EOQjCn4-9XY
• 14 August 2020: 2003-4, that is.
• 14 August 2020: We had the same values and principles when we were a remote young team working on a new product too. When we built v1 of Basecamp in 2004 David worked 10 hrs a week remotely from Copenhagen.
• 14 August 2020: That said, there are times when you can't learn without building something. So you could allocate six weeks to an R&D project where it's understood you are spiking and trying to stand something up to learn. See this bit on R&D mode: https://basecamp.com/shapeup/2.3-chapter-09#new-products
• 14 August 2020: Re: making a six-week cycle to explore the architecture ... in general I would consider such things to be part of the shaping process, outside of cycles. Shaping includes spiking and researching tech possibilities.
• 14 August 2020: For example, I worked on a side project in RoR recently. The project required running a very specific statistical algorithm. Since Ruby didn't have the right libraries, we understood we needed to consider choice of library and platform (calling out to a Python script) in shaping.
• 14 August 2020: A decision that big would be part of the shaping process. We wouldn't shape something and bet on it without having sense of what it requires architecturally. And since shaping and betting happen at higher levels, leadership would be aware and part of that decision.
• 14 August 2020: Going live in 45 mins. https://twitter.com/rjs/status/1293617875081555968?s=20
• 14 August 2020: Surprisingly good bit about Steve Jobs and the value of being pushed hard by editors and "bosses." https://www.youtube.com/watch?v=RppZLyeADaU
• 14 August 2020: Kauffman's screwdriver: https://www.wbur.org/npr/135113346/there-are-more-uses-for-a-screwdriver-than-you-can-calculate
• 14 August 2020: Boosts aren't going anywhere. We use them the same way.
• 14 August 2020: Why shipping is a one-way street. It's Kauffman's screwdriver. Novel hires on 1st order ("I'll use this to acknowledge without bothering others") become habits, become requirements back onto the product ("don't remove the ability to quietly acknowledge.") https://twitter.com/subendranRV/status/1294014643489275904?s=20
• 13 August 2020: Problem is lots of things sound pragmatic. Then it’s time to implement and it turns out you can’t get everything you wanted.
• 13 August 2020: Of the tasks like this (with multiple assignees and steps to the task) ... how many do you have in play at one time?
• 13 August 2020: A synonym for “getting real” is “making trade-offs.”
• 13 August 2020: I see. So it sounds like you have a task that isn’t really one task, it’s a series of tasks. And it’s hard to track where that is, what stage it’s in?
• 13 August 2020: Curious: Does assigning not work for that? Why not?
• 12 August 2020: Doing another Shape Up Livestream this Friday at 11am Mountain time. I'll interview Pablo Pinto, Product Manager at @g2i_co about how his team adopted Shape Up and answer questions about any challenges they're facing. https://www.youtube.com/watch?v=EOQjCn4-9XY
• 12 August 2020: Specifically in the architecture world it's a battle against construction and political processes. In the software world we have much more freedom. Some companies adopting our Shape Up process for example are doing it well.
• 12 August 2020: The industry is set up in a way that goes against everything he was trying to do. The Yakuza even offered his client a big bag of cash to fire him so he wouldn't shake up the way business was getting done.
• 12 August 2020: Trying to show what ROUGH early work looks like here. Projects don't start with wireframes or Figma! They start with words and illegible sketches. https://twitter.com/rjs/status/1293370647964299264?s=20
• 12 August 2020: Thread. If you scroll backwards to the start, you'll see how this began with talking an idea out in words, then made its way toward choosing a place to start, and finally arrived at some rough sketches. In the end it kicked off a new angle for tomorrow. https://twitter.com/rjs/status/1293366526351794176?s=20
• 12 August 2020: This still might not work out, but trying to draw actual UI solutions was "getting real" enough to bump into lots of problems and get closer to some decisions about the concept.
• 12 August 2020: I switched to Notability and drew some breadboards. After trying a few things, I realized that "choosing batch destination" overlaps with the existing "due date" and scheduling features. Had an a-ha and played with a new option that sets when to "do" something. pic.twitter.com/4CSbLy5CPr
• 12 August 2020: Then struggled to decide where to start, because there were lots of overlapping problems. So I drew an interrelationship diagram. The diagram said "choosing batch destination" was the place to start. pic.twitter.com/jQXGL88G6x
• 12 August 2020: Followup: Felt I needed to back up and spell out the different types of movements. Drew a diagram and then simplified it to see the types of movements I thought we might want to support for this idea. pic.twitter.com/7sEY8V2IiX
• 11 August 2020: Ten years ago!
• 11 August 2020: No. I use layers to lock certain background elements so they aren't selectable when I'm trying to make a jig. Eg the big rectangles in the screenshot above are part of the jig not the actual work so they aren't selectable.
• 11 August 2020: I find an outliner to be too constrained. I want a canvas so I can place things in specific locations so they mean more to me when I look at them. Zoomed out: pic.twitter.com/zydEL1t9Y3
• 11 August 2020: My go-to is handwriting in Notability on iPad with the Pencil. But sometimes I'm on the laptop and just want to quickly breadboard something out to get it out of my head. In that case I'll reach for Whimsical or OmniGraffle.
• 11 August 2020: Design isn't just about visual decisions. The earliest phase of a design is more like creating and speaking a language. Asking ourselves: What are the main ideas and how do they work together? pic.twitter.com/O5izeUQ2AX
• 11 August 2020: Good example of the value of prototyping. We get to try out language and then luckily we sometimes find things that stick.
• 11 August 2020: Trying to sketch the form made me realize I didn't understand some details about the context. Eg when do you want other people to know that you've put something on your private list, vs. when is that act itself private. This question / potential misfit started another round.
• 11 August 2020: Part of doing that involves shuffling the work around ... from "what I'm doing now" to "maybe in the next batch" etc. I've observed people doing this in text documents today. The form here has to do with offering ways to move the work in, out, and between these private areas.
• 11 August 2020: In short, I've defined the context as some functions that people want to perform. They are related to defining a private batch of tasks to work off of, from a big list, to reach a feeling of accomplishment.
• 11 August 2020: All you see is form here. Would require a whole case study to explain the context as I understand it, the attempt at some form, the bad fit that I saw, and then the next round.
• 11 August 2020: This breadboard was an example of getting something out of my head in the fastest way possible. I've already thrown it out because it revealed problems in the idea. Not worth spending time on some fancy diagram. Just need the minimum representation to reflect and learn.
• 11 August 2020: That is, whether the random walk falls off a cliff may matter. Even if the process that generates the random walk itself isn't path-dependent.
• 11 August 2020: Still boils down to a question of whether the path matters for the question we're trying to answer, no?
• 11 August 2020: Example of fast and cheap breadboarding in @WhimsicalPowers . If you don't fuss too much, it's nearly as fast and flexible as handwriting. Cut some fuss here by leaving out the horizontal line and just bolding the name of each place. pic.twitter.com/TG1jq2VgQM
• 11 August 2020: "Non-ergodic" is just a complicated way of saying: to understand this phenomenon, we have to look at the story over time for each agent.
• 11 August 2020: Simplest: Non-ergodic means the path of the process matters. Like a story. Ergodic means the path washes out in an average, like the movement of gas particles in a container.
• 11 August 2020: Check out the End of Average by Todd Rose for a short and very accessible primer on this.
• 11 August 2020: Yeah that stuff doesn't work. What matters is intent and trade-offs at the n of 1 scale. Then you can aggregate up, but if you don't start with an n of 1 process through time you don't have a coherent model.
• 11 August 2020: There are different levels. - The screwdriver transfers torque to the screw via the screw head. - You drive the screw to fasten the mirror to the wall. - You place the mirror at the end of the hall to eliminate the feeling of dead space that was there.
• 11 August 2020: This idea that causality is elusive is a fallacy. When you want the car to stop, you push the brake. There is clearly a model of cause and effect working there. All actions that people take are based on a model of cause and effect.
• 11 August 2020: After 16+ years of studying Christopher Alexander’s work, I finally digested enough to make room to look closer at the “15 Properties.” Using Battle as the starting point. pic.twitter.com/ypSl2nzWbM
• 11 August 2020: That is, "when X happens people are trying to do Y... therefore the system needs to do F()."
• 11 August 2020: My hunch is it's less about the system and more about the actual content of the research. If the research produces causal statements, then you can draw connections between functions in demand space and in supply space. Research that is correlative or attribute-based breaks down.
• 11 August 2020: For things the app does... that's the end of the story. For things that people do ... you could substitute other solutions in. But either way, they need to do that thing.
• 11 August 2020: The first thing is something the app does. The second thing is something people do.
• 11 August 2020: Probably because it was a eureka in the bathtub. It's very rare to see people do the research and the subsequent steps with so much rigor that you can trace a line through with enough confidence to tell the story.
• 11 August 2020: "Trigger a notification to this person" is a supply-side function. "Get this person to look at it when I'm not sure if they are able or willing to do it" is a demand-side function.
• 11 August 2020: IMO better to go with the grain than against. Declare anything that isn't research based as "fiat" strategy and roll with it. Then whenever there is a struggle, juice it as much as possible to get bona fide insight.
• 11 August 2020: What something is vs. what is does has multiple levels. On one level, Basecamp's @ mention feature notifies people about some content. Up a level, people use @ mentions in the description of a to-do to ask someone to look at it when it isn't inappropriate to assign it to them.
• 11 August 2020: A lot of researchers struggle to get other people to care about research. This is a basically a dead end. Better to look for situations where people are struggling hard with a question. Then there's a context to value it.
• 11 August 2020: Yeah in general people don't care about the research unless they themselves are struggling with the question the research answers. The rest of the company cares more about the "so here's what we should do" that comes out of the research.
• 11 August 2020: That led to ideas about which functions are missing in Basecamp, which led to the whiteboard explosion.
• 11 August 2020: I interviewed a bunch of fellow employees at Basecamp about what they do when (a) someone asks them to do some work or (b) they need to choose some work to do that isn't project-based. Then drew out the systems each person is hiring to do different functions in the process.
• 11 August 2020: This is an example of unpacking and packing. First unpacking scribbles on the whiteboard as many functions to (maybe) implement. Then packing those into systems that might be separately tackleable (so it's not one giant impossible project). https://twitter.com/rjs/status/1292993223388889090?s=20
• 11 August 2020: Anything is ok. Just depends on what problem you’re solving. S is system here.
• 11 August 2020: Narrowing down an explosion of ideas after a research project to a few systems to start designing. pic.twitter.com/gZrsuieNjr
• 10 August 2020: Thanks to @ziburski the pronunciation question is solved. pic.twitter.com/qskzbHiesh
• 10 August 2020: This is going to be very good. https://twitter.com/bmoesta/status/1292889351731531781
• 10 August 2020: That’s the idea. I don’t formally use the model on real projects — it’s more of a pedagogical thing. The absolute important thing is that the circumstance and outcome (x,y) are EMPIRICAL, not made up. Those things come from interviews or hit-you-over-the head life experiences.
• 9 August 2020: The key point is to track options, not make commitments.
• 9 August 2020: Yes: https://open.spotify.com/show/133Rj57EfSa4r1wbn2fNOL?si=qBUHIVA_SUm1j7QqOMk5zg
• 9 August 2020: So pleased to have found an occasion in this episode to share Gian-Carlo Rota’s fantastic, underappreciated paper: “Fundierung as logical concept.” https://www.jstor.org/stable/27903124?seq=1
• 9 August 2020: ⭐️ Synthetic A Priori: Episode 9 Christopher Alexander's concept of "life." What something "is" versus what it "does." Husserl's fundierung as a relation between function and form. And "life" as an explicit layer of software design. https://synthetic.transistor.fm/episodes/fundierung-and-the-level-of-life
• 8 August 2020: Getting Real?
• 8 August 2020: It’s a way of connecting them, yeah. This is an updated version of the same idea: https://feltpresence.com/functions.html
• 8 August 2020: Yeah Shape Up is all supply-side.
• 8 August 2020: Demand Thinking is about what goes into the front of the Shape Up process.
• 6 August 2020: "Sources of instability" — that's a good framing. On the flip side, we talk about "pouring concrete" at Basecamp: committing to things we know we won't be able to change because they embody foundational assumptions in the architecture.
• 6 August 2020: Christopher Alexander's talk to an audience of programmers in 1996. His "part three" amounts to a job-to-be-done perspective: go beyond the role of technicians and focus on what the software does in the world and how it affects the lived world. https://www.youtube.com/watch?v=98LdFA-_zfA
• 6 August 2020: Clay Christensen's book Competing Against Luck also suggests a different way to frame optimization — as targeted efforts to change the growth rate of problems ("pushes" in the book's framework). This way of thinking inspired a new approach to discounting: https://arxiv.org/abs/1910.02137
• 6 August 2020: Thanks for this episode. It reminded me to suggest @ole_b_peters as a guest. While I mostly agreed with this episode, IMO saying people "don't optimize" overshoots. It skips the question of what people optimize and when. Ole's work on time avg growth rate hints at new answers.
• 6 August 2020: Another example: https://m.signalvnoise.com/keep-digging/
• 6 August 2020: Here’s an example: https://m.signalvnoise.com/how-i-wrote-shape-up/
• 6 August 2020: IMO microservices far overshoot. Most teams struggle with basic factoring. But in the abstract yes I appreciate the point about learning where the boundaries are over time.
• 6 August 2020: (That is, I was thinking a better partitioned system had more margin because it would allow for change in a way that a poorly partitioned system wouldn’t.)
• 6 August 2020: Going in, I thought that the partitioning itself was margin. Any pointers on where to better understand what you mean by “placing margin” and what design margin even is?
• 6 August 2020: Pick one product to start, learn the context/outcome for that, then move on to another. Get the first order clear otherwise things will be muddy when you try to understand at the portfolio level.
• 6 August 2020: ^ That’s what we mean by “detailing the job.” The job is the big arrow. The detail is ... ok what are the challenges along the way, the specific things that have to get checked, things that should happen and not happen, etc.
• 6 August 2020: Once you have the “arrow” — a particular cluster of pushes/pulls — then you can look into that and say ok... what are the patterns in terms of anxieties that come up along the way doing this job.
• 6 August 2020: I missed the “how come” part. The context and desired outcome (pushes and pulls) are what differentiate the jobs. That’s the arrow from A to B that defines progress. The habit and anxiety are more like friction along the way. They’re important, but they don’t point the arrow.
• 6 August 2020: Just use the pushes and pulls for coding. You can detail the jobs with habits and anxieties later as needed.
• 6 August 2020: Follow the stuff I've written about jobs to be done, but don't know how to put it into practice? Here's an opportunity to learn. https://twitter.com/bosconference/status/1290996792314691586?s=20
• 6 August 2020: And ... this is important ... it's empirical! Don't speculate or fill in the demand side with made-up obvious-but-wrong answers like "to make it look nice."
• 6 August 2020: I'm guessing in your case "typography" is in some fuzzy way the "chocolate." People buy typography (or spend time on it... etc) in specific circumstances for specific desired outcomes. Those shape what matters and doesn't matter for the vendor. That's where to dig.
• 6 August 2020: Ok, to extend your analogy.. a chocolate-maker also has to make trade-offs. Snickers and Milky Way aren't made with imported Swiss chocolate. How does the chocolate "supplier" make trade-offs? By looking at the dynamics of the demand. It's the same at every link in the chain.
• 6 August 2020: Eg. you can average out how a bunch of gamblers perform. That avg is informative to the house. But for the gamblers themselves, it matters if they win or lose. Here the gamblers are the gas molecules. Their individual paths matter (...when they want to buy bread the next day).
• 6 August 2020: The reason you hear about 'ergodicity' now is because folks like @ole_b_peters and @nntaleb noticed a widespread error: people treat processes in many domains as if they were the gas molecules in the chamber, when those movements don't actually average out.
• 6 August 2020: An ergodic system is a special case. Like gas molecules in a chamber. You don't care about the path of each molecule. You just average out and look at the pressure of the chamber. Any time you care about the path or sequence of a movement, that's non-ergodic. That's all it is.
• 6 August 2020: The house and the garden have interdependencies with each other because they share the same lot. The garden has more interdependencies with the surrounding space, direction of sun, etc. than the house does.
• 6 August 2020: Another word for non-ergodic is "path-dependent." With ergodicity out of the way (it's not relevant because all design process is non-ergodic...), a better way to think about this is probably via dependencies.
• 6 August 2020: It's not a matter of degree. Either a process is ergodic or it's not. Whenever sequence matters, that process is by definition non-ergodic.
• 5 August 2020: That one is particularly abstract.
• 5 August 2020: If there’s anything that seems interesting but is hard to follow, feel welcome to DM or ask here for clarification.
• 5 August 2020: I’m sure it’s less about smarts and more about degree of overlap in terminology and context. Part of my concept for the podcast is to first overshoot, then select the things people found compelling enough to struggle with, then backtrack and try to present those more clearly.
• 5 August 2020: This was all in the context of trying to get a job. Your essay doesn’t need to be breakthrough. No need to try and create a new contribution to the field. It’s more about demonstrating competence and showing what you can do as a process not as a delivered artifact.
• 5 August 2020: Yeah the quoted thread is effectively about marketing.
• 5 August 2020: The best essays are more about the second order than the first (because they therefore apply to multiple cases). These interesting essays use the first order chain of events as an opportunity to comment on how you think about, frame and solve a problem.
• 5 August 2020: This is important, but IMO “write an essay” is not very actionable. The hard part of writing an essay isn’t just the writing—it’s coming up with something to say. Suggestion: Pick a problem you solved. Write a case study. Add 2nd order comments—how/why you do Y when you see X. https://twitter.com/patio11/status/1290854152277389313
• 5 August 2020: Fascinating bit from the end of this podcast... @DReinertsen talks about “design margin” to describe how robust a design is to changes. This is a different frame for thinking about “clean code”—not as a philosphical pursuit but as an economic choice. https://twitter.com/rjs/status/1290796928968429568
• 5 August 2020: Typically fantastic-looking work from @craigmod . His stuff shows what you can do when you integrate high levels of design+build in one person. (See also: Craigstarter, his new crowdfunding tool for Shopify.) https://shop.specialprojects.jp/products/kissa-by-kissa
• 4 August 2020: Reinertsen ( @DReinertsen ) on sequencing work in product development to reduce risk. https://overcast.fm/+XERfroXvw/22:48
• 4 August 2020: Any chance the recording will be available? Sounds fascinating.
• 4 August 2020: Good collision of topics from @StatModeling here relevant to JTBD interviews. Stories are valuable to the extent they reveal model misfits. New insights come from anomalies. This is @nntaleb 's minority rule in the context of longitudinal data. http://www.stat.columbia.edu/~gelman/research/published/storytelling.pdf pic.twitter.com/q2s4hAOqJt
• 4 August 2020: Generally speaking I would do the first couple chapters of Notes on the Synthesis is Form, then jump to the case study in Battle, then flesh out with Nature of Order Book 2. But starting point depends on you.
• 4 August 2020: Hey Matt! Since the key points are spread out over 15 books, it’s hard to say. I did this overview lecture to point out key ideas with references to the books along the way: https://www.youtube.com/watch?v=XLsTZXT0FlM
• 4 August 2020: See this lecture for an overview: https://www.youtube.com/watch?v=XLsTZXT0FlM
• 4 August 2020: FWIW I would not discount the intentions of those first wave people (like Kent Beck, etc.) They were looking for a better way to work within the constraints they were in: software teams that don’t set their own requirements and don’t define the user-facing strategy.
• 4 August 2020: To better situate Reinertsen’s work, we can say it goes deep on the supply side. Less about what to build, more about how to design the way we build, the way we organize, the way we schedule work ... all through economic trade-offs. JTBD is complementary on the demand side.
• 4 August 2020: Alexander’s work is about the design of structure and what it does for people. Not about how to cut lumber. Construction matters. But the deeper ideas become applicable when we look at the integration of construction, design, and desired outcomes.
• 4 August 2020: We’re seeing a revival of interest in Christopher Alexander’s work because software is no longer made by programmers alone. The first wave of interest was about implementation problems, not human outcomes. Design and strategy are more integrated now, bringing outcomes into focus.
• 4 August 2020: Don Reinertsen ( @DReinertsen ) has such a deep knowledge of product development. What he says is consistent w/ our views at Basecamp, but spelled out with more economic rigor and informed by broader experience in large industries. Recent podcast interview: https://overcast.fm/+XERfRDoVY
• 4 August 2020: Thanks. Any particular subject?
• 4 August 2020: Nature of Order 2 is a feast. Not something you just read through, but there's a lot in there.
• 4 August 2020: Longitudinal in the sense of longitudinal data — following one process over multiple points in time.
• 4 August 2020: Yes, I enjoyed it.
• 4 August 2020: Yeah very good. I just linked it earlier today. https://twitter.com/rjs/status/1290377410542628864?s=21 https://twitter.com/rjs/status/1290377410542628864
• 3 August 2020: The good people at By Design in Bratislava published a talk I gave in 2018 about Stuart Kauffman's work-constraint cycles. (The pictured part starts at 12:04). https://lab.bydesignconf.com/before-designing-a-solution-make-sure-you-found-the-real-problem/ pic.twitter.com/IPK2PLScU3
• 3 August 2020: Summary below. Study here: http://3m.com/vas/study pic.twitter.com/6RDAsLMAEg
• 3 August 2020: Innovative tool from 3M: Eye tracking without the eye tracker. Uses simulation to guess where peoples' eyes will go subconsciously, when they first look. https://www.3m.com/3M/en_US/visual-attention-software-us/ Example from http://feltpresence.com : pic.twitter.com/u18gOhHzNn
• 3 August 2020: "Improve the longitudinal process" — Yes, that's the overlap!
• 3 August 2020: What constitutes a “small world” is relative to a reference frame. A single new feature to design could be a “large world” if there are enough uncertain interdependencies.
• 3 August 2020: Interesting. The guests in this excellent EconTalk episode distinguish between “small world” and “large world” problems. They describe regimes of uncertainty that seem to map to thin vs. fat-tailed variables. https://overcast.fm/+JA1BMf8
• 3 August 2020: Great observation.
• 3 August 2020: Check out Competing Against Luck for a primer and context around that.
• 3 August 2020: Hey Kris! I would suggest looking at it through the lens of the anxiety force in JTBD. If somebody didn't have any "what if" questions in their mind, there'd be no need for a trial. Trial experience should be designed around the "what ifs" and "what abouts" to eliminate them.
• 3 August 2020: pic.twitter.com/7xFhSEqJ99
• 3 August 2020: Choosing a site "let's think of this as a new report ... not a notification..." means picking the outer walls, giving them more shape and detail, then figuring out the main parameters of the design inside.
• 3 August 2020: In terms of Taguchi methods, site selection maps to setting the outer wall on the system design (within which we do parameter design). Site selection is like looking at a variety of different possible outer walls, black-box style.
• 3 August 2020: Site selection comes before shaping. Shaping happens on a site. Eg If I decide this is about to-do items, I can shape a solution that modifies the to-do design. But there may be a totally different approach, outside of to-dos.
• 3 August 2020: There's a step in product strategy akin to "site selection." I'm hearing about a struggle from users... I think I understand the problem from the demand side ... now what part of the system might this affect? New feature? Change to an existing feature? Over here or over there?
• 2 August 2020: I also love how the intense colors of the UI put you into a kind of “playroom” headspace. The environment invites creativity. pic.twitter.com/HvmPDvJdqz
• 2 August 2020: And lots of very solid UI ideas in the latter half of this article explaining the backstory of Gatemaker: http://www.rainmagazine.com/archive/2014/gatemaker pic.twitter.com/1hvUAm7snB
• 2 August 2020: This is a completely different way to think about interface design. Don't be distracted by the colors. Focus on the process. Gatemaker, by Greg Bryant in collaboration with Christopher Alexander in the 90s. https://www.youtube.com/watch?v=o8b7ZBWGmu4
• 1 August 2020: Rather than draw a line from one to the other I would just say wherever we can work with a humanistic motivation and clear thinking, it’s a helpful thing.
• 1 August 2020: A Pattern Language: https://www.amazon.com/Pattern-Language-Buildings-Construction-Environmental/dp/0195019199/ref=nodl_
• 1 August 2020: Updated the lecture on Christopher Alexander with an outline and timestamps. https://www.youtube.com/watch?v=XLsTZXT0FlM pic.twitter.com/U9DUF5eFlH
• 31 July 2020: Not about processes being static or dynamic. Any process is by definition dynamic. Just about two perspectives: we can look at a design as a static artifact and then talk about it’s current structure, or we can talk about the process that creates the next version of that.
• 31 July 2020: Fantastic feature of @streamyardapp : When your connection stalls, they immediately give you feedback by blacking out your video and showing a spinner. Makes you perfectly aware of what got cut so you can repeat yourself.
• 31 July 2020: I haven’t suggested anyone go read about the 15 properties. I felt it was too big of a leap. Love the idea of building some kind of design training based on those, though, for people to consume if they’re personally motivated.
• 31 July 2020: It’s very socially costly to answer “yeah but we might need it one day ...” with “I don’t care, I’m deleting it.”
• 31 July 2020: It’s because of fear of getting rid of the item. For an individual contributor, the cost of the mess is less than the fear. For management, the cost of the mess is higher, but removing items is expensive at 2nd order: freakout from all the contributors.
• 31 July 2020: Interesting. Using betting as a way to test statistical hypotheses. Preprint here: https://rss.org.uk/training-events/events/key-events/discussion-papers/ (via @HarryDCrane ) pic.twitter.com/nbhWCRceOY
• 31 July 2020: Did some research on to-do behaviors today. Big asymmetry: to-dos are easy to add and hard to remove. Almost impossible to get the consensus necessary to remove something from a list. Need more options besides "done" and "archive" to deal with this.
• 31 July 2020: The recording of my talk on Christopher Alexander is online. This was a prototype. Will likely turn into an article. Covered the fundamentals: form/context fit, "life", centers, generative process, per-project pattern languages. https://www.youtube.com/watch?v=XLsTZXT0FlM
• 31 July 2020: Going live in an hour. YouTube link in the tweet below. https://twitter.com/rjs/status/1287914974484914176
• 30 July 2020: Reminder: Tune in tomorrow at 10:30am Mountain Time. The lecture will cover some fundamentals of Christopher Alexander’s work, followed by a case study in product design. I’ll take some questions from the chat afterward. YouTube link: https://www.youtube.com/watch?v=XLsTZXT0FlM https://twitter.com/rjs/status/1287914974484914176
• 30 July 2020: Start with Competing Against Luck by Clayton Christensen.
• 30 July 2020: We don’t have a good system for that currently. It’s something I’m thinking about for BC4.
• 30 July 2020: For a proper reframing of preferences and utility, see the Job to be Done framework by @claychristensen @bmoesta et al. That’s the way to think about demand: as dynamic circumstantial categories. For technical foundations, @ole_b_peters and colleagues at LML are making progress.
• 30 July 2020: Behavioral econ is mostly wrong too. Context makes the irrational rational.
• 30 July 2020: @Paul_Johnson It's comically wrong in all of its assumptions. Like the old physics joke: "Assume a spherical cow..."
• 30 July 2020: If you assume the work is known, then when things go wrong, the team must be the problem. Assume the team is good and treat the work as the unknown. Different null model. Makes it way easier to collaborate, challenge each other, and ask hard questions. https://twitter.com/rjs/status/1288675536940670977?s=20
• 30 July 2020: An essential point emerged in a Q&A yesterday about hill charts ... At Basecamp we don't check hill charts out of mistrust for the teams. We check hill charts because we don't trust the WORK. Is it scoped right? Does it entail what we expected? Is it solvable like we hoped?
• 30 July 2020: Out of curiosity / diligence, I checked out a microeconomics lecture from MIT today. Total nonsense. No discussion of opacity or circumstance. The model assumes explicit knowledge of globally applicable preferences and builds up from there. Econ is long overdue for an overhaul.
• 29 July 2020: Then the question becomes ... is the judgement actually unique case by case, or can it be standardized? If standard, you get scale by repeating the same rule. If not standard, you scale with many individual decision makers using their own judgement.
• 29 July 2020: A better example is using their judgement vs. following a predefined rule to decide. The manager judging case by case is equivalent to frontline judging case by case re: degrees of freedom. The scale transformation happens when judgement is replaced with standard protocol.
• 29 July 2020: It’s showing a trade-off. More scale from a central decision maker at the cost of lower complexity and vice versa. “Better” depends on the complexity of the task to be coordinated.
• 29 July 2020: No.
• 28 July 2020: This work gives formal grounding to many of the things expert practitioners know about system design, organization design, and risk management.
• 28 July 2020: Good new reference on complexity, scale trade-offs, and the relation of interdependencies to risk: https://www.hindawi.com/journals/complexity/2020/6105872/ pic.twitter.com/cwLSZFOq0U
• 28 July 2020: Instead of putting the fireplace where it was in the drawing, Alexander’s team moves it to where it should be and then changes the drawing. Reality > Drawings. pic.twitter.com/Cy3EaNRznO
• 28 July 2020: From an FT Lex column today on remote work. This is true; remote has a flattening effect. Never thought about it before, but Basecamp’s remote structure has probably enabled and prolonged our flatness as we’ve grown. pic.twitter.com/cwNExeCjHj
• 28 July 2020: ‘Supply and demand’ map more clearly in a business context and there’s less ambiguity.
• 28 July 2020: I got to ask Clay Christensen a question on this livestream in 2016. His answer shows how job-to-be-done theory actually obsoletes the definition of performance from his earlier disruptive innovation theory. https://youtu.be/Op6dYnkxD_w
• 28 July 2020: I’d be very curious to see that. Just searched and I couldn’t find any way to get the paper online.
• 28 July 2020: The main sources for the lecture on Alexander will be: - Notes on the Synthesis of Form - Nature of Order Book 2 - Battle An unorthodox path. If we succeed, you’ll see his more well-known books (The Timeless Way and A Pattern Language) as supplemental. https://twitter.com/rjs/status/1287914974484914176
• 28 July 2020: Ok let's do this. On Friday morning at 10:30am Mountain Time, I'll give a livestream lecture on Christopher Alexander. It'll be an overview of his most important ideas and a primer for people who are new to his work. Join live to ask questions. https://www.youtube.com/watch?v=XLsTZXT0FlM
• 27 July 2020: Yes it’s true.
• 27 July 2020: Exactly.
• 27 July 2020: Inherited the term “spiking” from Kent Beck et al. It’s a spike because it looks like this It’s a short, intense exploration into the depths of something to answer questions. Contrast with a project, which is a longer effort with a different shape. pic.twitter.com/DmkodyokSg
• 27 July 2020: Foo can be perfectly encapsulated. But if you don’t figure out how to make its internals work, you can’t integrate with bar to do what project X is supposed to do.
• 27 July 2020: In real design problems we have to set the boundaries between components AND their inner structure AND their outer relations. You factor project X into two parts: foo and bar. Where does foo end and bar begin? How does foo work? How does bar work? Do they integrate together? Etc
• 27 July 2020: Your definition above assumes the thing you are encapsulating is known. This is true if you are using an off-the-shelf component that is encapsulated. This is not true when you yourself have to design the encapsulated thing.
• 27 July 2020: That shipping case study is a beautiful example of defining the boundaries of a system. pic.twitter.com/uwc6ukMLgr
• 27 July 2020: Martin Fowler’s Refactoring is full of examples. To go deeper in the software area, look at Eric Evan’s Domain Driven Design, specifically how he remodels the shipping problem.
• 27 July 2020: Oftentimes we’ll say: this part is a tangle of hard questions. Do we need it? If we can still do something valuable without that, we’ll cut it from the scope and bet on the part we understand. If we need it, we’ll use strategies to learn more before betting. Eg spiking.
• 27 July 2020: It’s via negativa — we should we not do. If we find a rabbit hole while shaping, we don’t give it to a team with fingers crossed. We either eliminate that piece from the project or structure time to learn so we can fill the hole.
• 27 July 2020: We can have a perfectly encapsulated part of the system. This means that from the outside, we are confident the boundary is in the right place and there are no ripple effects. But an unknown inside the boundary can kill the project.
• 27 July 2020: Encapsulation mainly refers to information hiding: giving yourself the ability to look at a part of the system from outside without caring what is inside of it. That’s relevant but only a small part of system design. Need to set where boundaries are, define unknowns in and out.
• 27 July 2020: Yeah. Encapsulation is an example of setting a boundary between outer/inner on a system.
• 27 July 2020: (In the latter example, there could be major implications for how we handle authentication... and that affects signup ... account management ... etc etc)
• 27 July 2020: Examples. If I don’t know what the language should be on a button, that’s an unknown at 1st order but it doesn’t have ripple effects. If I don’t know how to handle switching between multiple accounts, decisions on 1st order there can have many ripple effects on 2nd order.
• 27 July 2020: Two ways to look for opacity: 1) Given some first order thing, do we know how to do it? Or is it an unknown? 2) Then on second order, if we don’t know something, does that cascade to create further unknowns?
• 27 July 2020: It’s a question of opacity, not complexity. A complex project is okay if we know what we’re getting into. What’s not ok is a project that seems simple but turns out to be 10x or 100x more complex.
• 27 July 2020: Part of why it’s valuable to set clear boundaries on what’s “in” and “out” of a given problem you’re solving. These questions enable us to determine the properties of the distribution of the time estimate and set corresponding strategies. https://twitter.com/rjs/status/1287854230112317441
• 27 July 2020: Inner dependencies: whether the parts internal to the system you’re designing fit together in known ways or not. Outer dependencies: whether the edges of the system you’re designing fit with other systems in known ways or not.
• 27 July 2020: This is something we talked about on the Changelog recently ( https://changelog.com/podcast/399 ). We shouldn’t pad estimates to increase our safety. We should look harder at the work to determine its properties. Specifically, look at the inner and outer dependencies.
• 27 July 2020: Key point from @nntaleb ’s EconTalk episode today (highlighted). In product dev, this means looking at the type of work instead of just setting a numerical time estimate. Type of work (solving unknowns, connecting known parts, etc.) gives process, which gives “properties.” pic.twitter.com/GkjU5KOp8K
• 26 July 2020: Thinking about doing a livestream lecture on Christopher Alexander’s main ideas soon. More likely to get something out that’s helpful that way in a short period of time vs. writing a primer. Any questions or things you want to hear about?/
• 26 July 2020: No, the jobs are the jobs. All the big things we’re looking at for BC4 are about raising the quality of how we execute on them.
• 26 July 2020: I can talk about BC4 but not likely to do so on the show.
• 26 July 2020: ⭐️ Synthetic A Priori: Episode 7 Formally defining a market space to position a product. Turning three jobs that Basecamp does into a space. How struggles in market space set the value of opportunities and create design requirements. https://synthetic.transistor.fm/episodes/product-movement-in-market-space
• 26 July 2020: It's not abstract if the job calls for it. This is the point of the job. To give us concrete requirements. Eg joining a club to learn a skill is different from joining a club to feel you belong somewhere. Different concrete requirements for the experience design.
• 26 July 2020: "Make me feel happy" may be true but it isn't a design requirement. It's too abstract. We to understand a more specific circumstance in order to create the desired effect.
• 26 July 2020: Yes of course you trace things down to very deep psychological needs. But "I need to feel belonging" isn't situational enough to design solutions for. It needs to be embedded in a more specific situation (a job) to become operational.
• 26 July 2020: People have jobs, not things. By framing it that way, we can better see substitutes. That the loft can do the job is different from the loft having the job. Other things besides a loft can also do the job.
• 26 July 2020: Yes. And there's more context to downsizing than that. "Give me a place to figure out what's next" is going to be different from "give me a place to make my own" — one might be short term and furnished, the other long term and unfurnished. (I made those up to illustrate.)
• 26 July 2020: It's not philosophical, it's empirical. It's a question of what are people struggling with. What you call it doesn't matter. The point is we need to know both the context and the desired outcome to design a solution.
• 26 July 2020: To design something we have to know not only where people are going but also where they are starting.
• 26 July 2020: The latter. A need only specifies one thing: "I need energy." A job specifies context and outcome: "When I'm fading in the middle of a task and I have to keep going, give me energy." Snickers or steak dinner? The 'need' doesn't differentiate. For the job it's clear which one.
• 26 July 2020: Think about it: If you have a JTBD, but then you're hunting for some "underlying need", what good is the JTBD doing?
• 26 July 2020: The JTBD is the causal why. Review Competing Against Luck for a better sense of what a JTBD means. There isn't another thing deeper than that. The struggle and the design requirements are embedded in the job.
• 26 July 2020: My point was that "need" isn't the right framing. The JTBD itself is the impasse that we need to understand — something someone is struggling to do. Yes, understanding that is the basis for shaping.
• 25 July 2020: Check out Competing Against Luck to better understand what forces are. Then consider a course like this to learn interviewing technique: http://learn.jobstobedone.org/courses/JTBDinterviews
• 25 July 2020: I don't follow what you're talking about with metadata. The forces themselves are what we cluster on. No metadata. The point is to cluster in a way that is context independent.
• 25 July 2020: The output of each interview is a set of causal factors (“forces” in the jargon). We cluster on those. Sorry, there isn’t anything I can refer you to online yet that walks through the process.
• 25 July 2020: What has a structure is the process people go through: first thought → passive looking → active looking → deciding → purchase. The interview is about figuring out the cause and effect of how those things happened.
• 25 July 2020: There isn't a fixed structure for the interview. Think of it more like a criminal interrogation. You don't have preset questions for how you figure out if somebody committed the murder or not. You ask where they were on the night of the 10th etc.
• 25 July 2020: Langacker's Cognitive Grammar is more general and goes deep along that line of thinking that language is a special case.
• 25 July 2020: This is what we saw with a huge rush of HEY adopters. People weren't shopping for a new email service. But then when some people saw a new way, it highlighted the struggles that they had. The "B" is having more control and less email, not HEY itself.
• 25 July 2020: To your point, I think you were suggesting that supply can "create" demand. IMO more operational to frame like this: may not be conscious of an impasse until you see a solution for the first time. Then "OH, I always hated that!" and click.
• 25 July 2020: That framing conflates the desired outcome with the solution. The solution isn't point B. The solution is what GETS you to B.
• 25 July 2020: Whether people rely more on the forces or the timelines is individual also. I recommend learning the timeline first because it helps you to kind of mentally "check the boxes" and see if you have a full cause-effect chain or not.
• 25 July 2020: That's very individual. I type like a stenographer as I talk to people so that I can glance up and repeat their exact words back to them when asking for clarification (very effective technique). But that's just me.
• 25 July 2020: That depends on your sources. JTBD isn't one thing. Different camps.
• 25 July 2020: Yes. But "high effort to video chat" is a made up impasse. Whatever the impasse is, it's empirical. If they switch, it's because there was something they were trying to do that wasn't working with the status quo. Then discussion of cost and value should be based on this.
• 25 July 2020: That’s a special instance of the same thing. If cost wasn’t an obstacle to making it possible then cost isn’t a relevant parameter.
• 25 July 2020: See Competing Against Luck for an intro to this way of thinking.
• 25 July 2020: If you wanted to understand their relationships to each other in the market you could do interviews to determine what the “impasse” was for buyers of each. Then the question is to what extent they solve the same impasses, and where there are differences.
• 25 July 2020: Yes and crucially a bridge has two ends. Where people are coming “from” is as important to where they are going “to”, and why we have to understand what they are struggling with to know what to insert in between as the bridge.
• 25 July 2020: This framing makes it easier to see jobs as potential energy. The energy is built up by the obstruction. This then justifies the very fruitful but underappreciated viewpoint that demand actually precedes supply. It is a thing itself. Supply makes the potential kinetic.
• 25 July 2020: If the customer could have gone from A to B, they would have just done so without a new purchase or change of behavior. The problem was they couldn’t get to B. So they needed to apply some method to change the circumstance and make B accessible from A. That’s a “hire.”
• 25 July 2020: Needs are pointlike. They have no origin, just a destination. An impasse is pathlike. There’s an obstruction on the way to something else: from some A to some B. The “on the way to something else” is key to understanding demand.
• 25 July 2020: A job to be done is not a ‘need’ — it’s an impasse.
• 25 July 2020: Not specifically about interviewing technique. This one also touches interviewing, but from higher altitude: https://m.signalvnoise.com/how-i-wrote-shape-up/ Check Competing Against Luck by Clay Christensen for some basic framing around the interviewing.
• 25 July 2020: Also helpful to look at it as a natural growth process, something that is understandable from the circumstance they were in.
• 25 July 2020: More productive to look at all the things they did well and that made progress.
• 25 July 2020: The Innovator’s Solution
• 24 July 2020: FWIW I usually recommend people go straight to Solution. More generally-useful tools in there.
• 24 July 2020: I keep thinking about writing some kind of short tour through Alexander’s work for the benefit of people who haven’t done the long journey through. But it’s daunting. Maybe I’ll do a lecture sometime on it.
• 24 July 2020: Mainly Antifragile.
• 24 July 2020: I use it a bit. I don’t qualify as a “cult” member. I’m not a big note-taker. Def appreciate some of the innovations.
• 24 July 2020: For Taleb, I started with Antifragile. Alexander is harder. My top five of his books are combined 2,129 pages and IMO the key points are scattered across them. Maybe start w/ first half of Notes on Synth of Form. Then read Battle. Then fill a la carte w/ Nature of Order Book 2.
• 24 July 2020: Three types of books: 1. Books you can’t put down 2. Books you put down because you got bored/lost 3. Books you have to put down for a moment because they suddenly gave you too many ideas Nassim Taleb, Christopher Alexander, Clay Christensen all in the third category for me.
• 24 July 2020: Innovator’s Solution, Chapter 5 is unusual for a business book because it’s really about design. Predictable vs “unpredictable interdependencies” ... when to treat two things as one problem vs. when to define a boundary between them as two separate problems. Fundamental stuff. pic.twitter.com/n8dUpBH4yM
• 24 July 2020: Recommended https://twitter.com/bosconference/status/1286602437000859648?s=20
• 24 July 2020: People who currently use vs people who don’t.
• 24 July 2020: Wanted to explore an idea about value networks as systems of functions, and went to this book because it’s favorite reference on how to think about value networks.
• 24 July 2020: With the man himself in 2013. Such a huge influence. Very thankful. pic.twitter.com/oWEfTOCYf9
• 24 July 2020: Can’t pick one. Chapter One is a barrage of clarity.
• 24 July 2020: No, not necessary.
• 24 July 2020: I forgot how fantastic “The Innovator’s Solution” is. Absolutely worth a re-read. The bits about theory and causal mechanisms in Chapter One are essential. https://www.amazon.com/Innovators-Solution-Creating-Sustaining-Successful/dp/1422196577/ref=nodl_
• 24 July 2020: Wow. Apparently Clay Christensen’s “The Innovator’s Solution” (2003) was more influential on me than I understood when I first read it. This may be the first explicit presentation of “shaping.” pic.twitter.com/4RDt7LWCLw
• 23 July 2020: What type of benefit, for whom, at what scale, with what side effects, depends on choice of projects (and their success) at first order bubbling up to second.
• 23 July 2020: Ok shorter: product position is a higher order function of which jobs we design the product to do. 1st order: the customer benefits. 2nd order: the firm benefits.
• 23 July 2020: The choice of which progress to make for which customers — and whether those customers are consumers or nonconsumers — moves the product at the higher order.
• 23 July 2020: The vector of progress of the product for the firm is in a different space than the vector of progress of the customer doing a job. But these vectors are linked because the progress of the product for the firm depends on making progress on the second order for many customers.
• 23 July 2020: A project’s payoff from the POV of a customer is a different thing from the project’s payoff from the POV of the firm. These are somehow related as linked lower and higher orders. Some changes for customers bubble up as market position changes for the firm. Some don’t.
• 23 July 2020: Did some work today on the portfolio of potential BC4 projects. Fascinating to consider what a project does for a customer vs. what it does for the product. Which changes “move” the customer toward more progress, and which changes also “move” the product into a better position.
• 23 July 2020: It should respond to narrowing your window if you like a smaller size.
• 23 July 2020: Yes.
• 23 July 2020: Just shipped a couple small changes to the new Ch 9 in Shape Up. Clarified some fine points about how the switch from R&D to Production Mode in HEY wasn't completely binary. https://basecamp.com/shapeup/2.3-chapter-09#examples pic.twitter.com/QQ3W6lvT3a
• 23 July 2020: Clay Christensen’s BSSE at Harvard could be a relevant case study. Very unorthodox, became wildly popular because incoming students related more to the mateiral.
• 23 July 2020: I’d speculate that there is unsatisfied demand on the academic side as well from people new to the field who are hopeful for insight into a domain they find interesting.
• 23 July 2020: Meta-answer: Venture into the empirical to determine whether a) or b) is more helpful. Find when/where people struggle with standard economic theory and then select the approach that helps the most. a) and b) are both supply-side. Go empirical on the demand-side to select.
• 23 July 2020: Thanks!
• 22 July 2020: (To be precise, we do things that are analogous to User Story Mapping in the shaping phase. But we do them intuitively and informally.)
• 22 July 2020: We don't do User Story Mapping. But broadly speaking that kind of work belongs in the shaping phase. Whether you apply Shape Up or not, there's a phase of work that is more about figuring out what you're going to do and less about implementing it. That's shaping.
• 22 July 2020: Technical as it is, this book by @HarryDCrane is surprisingly readable. Good model of working both “on” and “in” a subject. Continually wraps the content in wider context, contrasts its approach with others, and places you within a field. Doesn’t just dunk you in the details. pic.twitter.com/atKpxeGvFo
• 22 July 2020: Took a look at the data today. To date, Shape Up has gotten over 500k unique visitors and continues to see ~1.5k uniques a day.
• 22 July 2020: Classic infographic principle: show cause and effect. https://twitter.com/wrathofgnon/status/912533249557012480?s=20
• 22 July 2020: This suggests a lot of design latitude for education. It's not about online vs. in-person. Each piece of the value network (exams, asking questions, lectures, peer collaboration ...) can be reevaluated/reintegrated separately, vs. changed as a monolith. https://twitter.com/nntaleb/status/1262726312554385410?s=20
• 22 July 2020: Thanks Hibai! Appreciate it.
• 22 July 2020: Thanks. I’ll look to see if I can find a way to bring them back that fits in the new structure.
• 21 July 2020: And for tone. I wanted it to be a little edgier. The dominant trend in web design and copywriting today is very sugary. Lots of casual “oh hi welcome to my site!” and cartoons and things like that. I wanted to go in the other direction.
• 21 July 2020: Purely stylistic — to look and feel different.
• 21 July 2020: The bet is on the main moving parts of the shaped work. Those big pieces of the work are the content of the bet. The sittings are down at a level of detail that the teams will figure out.
• 21 July 2020: Things at different scales are different things. Like, a body is made out of atoms, but it doesn’t make sense to describe it as atoms. Better to talk about arms, legs, hands. “Sittings” are like the atoms. From a betting standpoint, we don’t go down to that scale.
• 21 July 2020: Yeah I chose the edgier direction on purpose, even though I know it’s objectively less readable. Designs get watered down quick so I wanted to err on the side of different for v1.
• 21 July 2020: Don’t want it centered.
• 21 July 2020: To the original poster’s point, the more you have to plan or manage what people do when they sit down to work for a couple hours, the more everything grinds to a halt. That’s why we assign whole projects, not individual tasks, to teams. See Chapter 10: https://basecamp.com/shapeup/3.1-chapter-10
• 21 July 2020: The bets in Shape Up are at the scale of six-weeks, not at the scale of sittings. People on the teams choose themselves what to do in a sitting and self-organize, using the constraints of the shaped work.
• 21 July 2020: Which browser is that? There shouldn’t be underlines below the big links on the right.
• 21 July 2020: https://twitter.com/ole_b_peters/status/1285586509266124804?s=21 https://twitter.com/ole_b_peters/status/1285586509266124804
• 21 July 2020: First time using it. Really hacked it in — just with the CDN and no pre-processor setup. Edited the static files live on the server with vim.
• 21 July 2020: Yes. With another update coming — a reader just spotted a typo.
• 21 July 2020: Very random. I got the idea from a Balenciaga campaign that struck me as fresh.
• 21 July 2020: https://twitter.com/rjs/status/1278812958663962624?s=20
• 21 July 2020: Tried something new on this layout. Very small print. More scales. ( http://feltpresence.com ) pic.twitter.com/K4wPs1XkQj
• 21 July 2020: Old version was out of date and didn't easily accommodate the hierarchy I wanted.
• 21 July 2020: Gave the website a quick refresh. Flattened down to one page. http://feltpresence.com
• 20 July 2020: I don’t use confidence to prioritize. It’s a criteria for being in the set of options. Not a ranking. Among the things that I have confidence in, I can choose one to bet on. Among the things I don’t have confidence in, I can choose one to investigate further or prototype.
• 20 July 2020: Confidence is binary, not scalar. You either go to the next step or you don’t. When I’m not confident about something, I ask what I can do to learn. The learning technique I reach for (sketching, spiking, asking someone, interviewing...) depends on the type of problem.
• 20 July 2020: https://m.signalvnoise.com/the-fidelity-curve-how-to-weigh-the-costs-and-benefits-of-creating-ui-mockups/
• 20 July 2020: Thanks. Fixed.
• 20 July 2020: ⭐️A new chapter of Shape Up is live: "Place Your Bets" About how we place bets on new vs. existing products and the three phases of development we go through when building new products. With HEY as an example. https://basecamp.com/shapeup/2.3-chapter-09
• 20 July 2020: Worth checking out if you want to get your feet wet with complex systems topics like multi-scale systems, independence vs. ripple effects, probability regimes, etc. https://twitter.com/normonics/status/1285303821950955521?s=20
• 20 July 2020: "The notion that one new thing sometimes triggers another . . . has never been documented quantitatively." The Dynamics of Correlated Novelties by @stevenstrogatz and others. Relates to opacity and "discovered tasks" plus interesting ties to semantics. https://www.nature.com/articles/srep05890
• 20 July 2020: Glad to hear it and thanks!
• 19 July 2020: ⭐️ Synthetic A Priori: Episode 6 A network model of design, features vs. implementation as levels of a multi-scale network, Alexander's unfolding process, thin vs. fat-tailed risks, scopes as tangles https://synthetic.transistor.fm/episodes/design-as-a-multi-scale-network-thin-vs-fat-tailed-problems
• 18 July 2020: The maxim applies: "we only have data about the past."
• 18 July 2020: @bmoesta can probably answer better than me. From my experience: 1. Yes. Digging is hard and takes practice. 2. At the same time, everything doesn't have to come from an interview. Can note something suspicious and ask customers about it and learn if there's a story there.
• 18 July 2020: I imagine you could make up numbers by looking at the behavior you believe causally leads to, eg, churn, estimating the reduction in churn if you fixed that thing, etc. But I'm speculating.
• 18 July 2020: At Basecamp we (meaning Jason and David, who make the bets) work the other way around. We don't calculate numbers for upside, we calculate numbers for cost. If we like the cause-effect explanation of the feature, with unknown upside, and the cost is acceptable, we do that thing.
• 18 July 2020: https://twitter.com/rjs/status/1283549215268851712?s=20
• 18 July 2020: The new book by @nntaleb is beautiful. Love the red footnotes. Great proportions too. pic.twitter.com/YJep6Dr3zy
• 18 July 2020: Ah that looks more like it. Keyboard + trackpad but also folds fully.
• 18 July 2020: Yeah I started working outdoors at a coffee shop and that pushed me to switch. I liked the better keyboard on the new case but it wasn't adaptable enough when I wanted to switch to drawing, had limited space at the cafe table, etc.
• 18 July 2020: Reach out for a beta account if you get further beyond Competing Against Luck and start doing interviews.
• 18 July 2020: We must have different contexts. Are you moving between locations often or mostly using the iPad in the same place?
• 18 July 2020: Yesterday I put the fancy new Magic Keyboard Case for iPad on the shelf and switched back to the flip-cover case (the “Smart Keyboard Folio”). Magic Keyboard Case is incompatible with the Pencil. The Folio + Pencil works as a coherent whole.
• 18 July 2020: But after I had the core in place, the rest was easy to play out (as explained in that new Shape Up chapter). At that point I brought in some friends and starting delegating shaped work to them. That’s the flip to production mode.
• 18 July 2020: It was a short R&D process .. a few long days of solo work. Along the way I totally redesigned the UI and changed the underlying schema once or twice. It would not be practical at all to delegate that work to someone else. I’d have to look over their shoulder and micromanage ...
• 18 July 2020: Example from a side project. I’m working on a small app to manage data at each stage of the JTBD interview and analysis process. At first, I had no idea what the basic structure of the app should be. I sketched a couple ideas and got them barely-working in a Rails app. ...
• 18 July 2020: By definition “scrap” — stuff you throw away — is not valuable. There is scrap work at that phase because there are false starts. We can’t see what the right architecture is in advance. Re: the process, @dhh calls it “firing tracer bullets” per the Pragmatic Programmers.
• 18 July 2020: No we don’t test on customers. We develop our own understanding of the problem and design against that. At Basecamp we use the product ourselves as we go.
• 18 July 2020: They should be the same.
• 18 July 2020: Draft of a new chapter in Shape Up that explains the difference between placing bets on new products vs. existing products, with HEY as an example. pic.twitter.com/Etrxmk8LfJ
• 17 July 2020: Lots of tasks sitting around that never get checked off sends a clear message to everyone: don't trust this place.
• 17 July 2020: Nice answer: write them in a note. You probably won't ever need them, and if you do you can search the note later. More honest answer: in the trash. It's healthier and sets clearer expectations if we only create tasks for things we will actually do in the immediate future.
• 17 July 2020: We often identify scopes (tangles of interrelated problems) without even knowing what the tasks will be. The task will fill in later when we choose it's the right time to work on that scope.
• 17 July 2020: What we call "scopes" at Basecamp and in Shape Up are tangles of problems. When you work on a project, not every problem relates to the others. If you randomly select tasks, you can go in circles due to interdependencies. Pick a tangle to work on and name it. That's a scope.
• 17 July 2020: Things that can't be done in one person's work session ... ideas for projects ... things that we don't know how to do ... things somebody asked for that isn't shaped ... etc.
• 17 July 2020: So much churn, noise, and junk in our to-do apps comes from creating tasks that aren't tasks.
• 17 July 2020: Similarly, scopes aren't just an arbitrary grouping of tasks. Scopes have a content and a meaning: they point to a tangle of interdependent problems in the project.
• 17 July 2020: People know work has different scales (project > scope > task) but usually they track these as nodes on a tree. Ie. the project is just a name that points to smaller things. The project itself requires a description to set constraints on lower levels: shaping and a write-up.
• 17 July 2020: These weave together. Project scale (#3) describes demand & supply (#1). Carve time to finish (not just 2 weeks!) (#2) Scope scale (#3) is supply-side (#1). < 1 week (#2) Task scale (#3) describes supply (#1). Shouldn't take longer than one person's unbroken work session. (#2)
• 17 July 2020: 3. Scale You can't describe the world with atoms. Similarly you can't describe a project with tasks. The project scale isn't a name or sentence it's a write-up of shaped work. Mid scale is scopes: related areas to solve so a chunk of the project is done. Small scale is tasks.
• 17 July 2020: 2. Carved out time (!= deadlines) If you set a bunch of deadlines, the work just collides in the 11th hour and/or you have to play Calendar Tetris to slot everything in. Instead, carve out chunks of time at different scales (see #3) to do one thing and not other things.
• 17 July 2020: 1. Demand vs. supply side Some artifacts should describe the "why" and the context, others describe the "what" of how it works. Don't need "why" on every piece. Wrap many small "whats" with one bigger "why"" for context (see #3).
• 17 July 2020: Judging by the amount of struggle around "to-do" processes, we have barely scratched the surface of understanding the kinds of work teams need to manage. Three concepts help: 1. Demand vs. supply side 2. Carved out time (!= deadlines) 3. Scale
• 17 July 2020: Exactly. Confidence x payoff are the two important things.
• 17 July 2020: Payoff is the most important dimension. How much do we GET from the effort.
• 17 July 2020: (Good connection between Shape Up and the confidence dimension. Shaping is about actively changing the definition of the project to increase confidence.)
• 17 July 2020: More important to look at confidence x payoff. Payoff is how happy we'll be at the end of the cycle having spent time on that thing. Confidence is our odds of getting the payoff.
• 17 July 2020: Low effort isn't a goal. There is nothing bad about hard work or hard problems!
• 17 July 2020: We often can’t see the size in advance. What we think is a small action can turn out to be more complicated than we thought.
• 16 July 2020: I think this is calling for a different tool than a to-do list. More of kanban kind of thing. I don’t have a good solution yet.
• 16 July 2020: I bet this is true for a lot of other people too. Going to think about how we can share this more widely.
• 16 July 2020: Yeah. Rework it into the thing someone should do about the concern.
• 16 July 2020: If you can't do it in one session, it's not a task.
• 16 July 2020: How big should a task be? https://twitter.com/rjs/status/1283862048594464768?s=20
• 16 July 2020: In general, I would avoid creating any tasks that are bigger than a work session (eg. an unbroken few hours of focus).
• 16 July 2020: You can make a task that generates other tasks. Label it as "investigate: ..." or "figure out ..." We have a quirky abbreviation: "PDI: " from a Davidism: "Please do investigate." It means, this isn't actionable.
• 16 July 2020: It's on the leadership team to figure this stuff out.
• 16 July 2020: This raises juicy questions about your software process: What is considered immutable and what is mutable? Which tasks are in stone and which aren't? Where is the latitude and where are the boundaries?
• 16 July 2020: Multiple people have said they feel "guilty" about rewriting a task to better reflect the work they did and what's left. Makes my job-to-be-done ears perk up. Evidence of struggle. /cc @bmoesta https://twitter.com/rjs/status/1283593211882045440?s=20
• 16 July 2020: Ceremony without understanding.
• 16 July 2020: Yes it's a paper shredding technique. User stories aim to make tasks "self contained" under the assumption that contributors will be randomly pulling things with no context. Good for bugs. Not good for project work.
• 16 July 2020: If I only look at one task after the other, they don't add up to something bigger that gets done. Too easy to wander and get lost or waste time. That's what this intermediate level of scale is about.
• 16 July 2020: Orthogonal basically means you can finish things separately. Tasks are by definition orthogonal. The more meaningful question is: which zones of tasks add up to a whole meaningful moving part of the project being "done."
• 16 July 2020: Note the ~ log scale. https://twitter.com/rjs/status/1283853846771412993?s=20
• 16 July 2020: Yup, wrong scale. Better to set appetite at the project level (how many weeks is this overall effort worth) and then shape a concept to that before committing the time.
• 16 July 2020: That makes sense for a bug. For normal project work, something is wrong if the developer doesn't already have the context.
• 16 July 2020: At the project level, the project is one thing: the shaping document (or pitch). At the scope level, the project is 5-10 things: the map of the scopes (we use to-do list names in Basecamp). At the task level, the project is hundreds of individual items capturing work to do.
• 16 July 2020: We shape the project and then present it with a written document. https://basecamp.com/shapeup/1.5-chapter-06
• 16 July 2020: Yeah that needs to be shaped into a project. Not a task.
• 16 July 2020: Examples: 1. A shaped project. (An overall concept for the whole project at the right level of abstraction.) 2. Scopes and tasks. Here scopes are represented as list names and tasks are the checkable items. pic.twitter.com/TinwVFF7Z3
• 16 July 2020: http://basecamp.com/shapeup
• 16 July 2020: Yes. A task that you can't check off after working on it for hours or days indicates a scale mismatch between the task and the work.
• 16 July 2020: Similarly, trying to describe a project with a "story" (which is more or less one sentence) is a scale mismatch at the other extreme. A project of any meaningful length deserves a write-up. Not a madlib sentence.
• 16 July 2020: Trying to wrap every task in demand context ("user stories") is a total scale mismatch. If I'm cooking dinner, I don't need to understand the needs of the customer to add "buy lettuce" to my grocery list. That context belongs up a couple levels at the larger scale of the effort.
• 16 July 2020: Largest scale: Shape. What's the project, how do we know when we're done, what's in/out. Medium scale: Scopes. What are the main orthogonal parts that make the system do what it should do. Fine scale: Tasks. What are the little things we discover we have to do to implement.
• 16 July 2020: In software dev, tasks (checkable items) are the wrong scale for planning. They're the right scale for capturing things you discovered and don't want to forget. Planning happens at larger scales: scopes (orthogonal chunks of the overall project) and shaping the project itself.
• 16 July 2020: We put much more effort into understanding the context at the project level. And then we don't need any funny ceremony around how we define tasks and scopes at the implementation level.
• 16 July 2020: There are so many things you just have to do and figure out. "Group the sent rows by thread." No need to artificially wrap that in some kind of "story." We know what it means. We know the context from the project it belongs to.
• 16 July 2020: In case it wasn't clear from Shape Up... Our teams at Basecamp have never written "stories." We create to-do items and lists that capture work we need to do or figure out. The demand-side of the work (the "why") belongs at a higher level: the shape of the overall project.
• 16 July 2020: Likely to announce a meaningful update to the Betting section soon.
• 16 July 2020: We also apply this same thinking to whole to-do lists (scopes in Shape Up). https://basecamp.com/shapeup/3.4-chapter-12#prompts-to-refactor-the-scopes
• 16 July 2020: No. Just some work to do.
• 16 July 2020: Lots of unchecked to-dos and lots of actually-completed-work means the to-dos as designed have low signal-noise.
• 16 July 2020: Undervalued to-do technique: If you can't check off a to-do at the end of the day, but did work on it, rename it to describe what you did. Then create a new to-do (or to-dos) to describe what's left. We know the least about what the work is when we first create the to-dos.
• 16 July 2020: We're open to the idea of accepting reader-submitted translations and hosting them. But we don't have any infrastructure in place to do that. /cc @AdamStddrd
• 16 July 2020: A shorter cycle is within the horizon, but the shorter it gets, the more you are trying to run while looking at your feet.
• 16 July 2020: Trial and error. We tried shorter and longer. I believe the number corresponds to a perceptual horizon. We can't feel a deadline further than ~ six weeks away. When we can't feel it, it doesn't push back on us to make trade-offs.
• 16 July 2020: It's a hard thing to judge from the outside. Every deal has trade-offs. Important thing is we're free to seek a different deal if we want one, and at a given time we're making the progress we want to make for our life situation.
• 16 July 2020: I look critically at what it means to "contribute to success." I attribute the position we're in as a company to a very small number of crucial decisions the founders made at the right time. It's a power law. Then the whole team works together to fill gaps and maintain altitude.
• 15 July 2020: Learning strategy: Start w/ something far beyond what you can understand but that interests you. Use it as a guide to decide which basics to learn. I'd rather try to understand the renormalization group than take Physics 101. In that spirit, just ordered https://www.amazon.com/Statistical-Consequences-Fat-Tails-Preasymptotics/dp/1544508050/ref=sr_1_1?crid=H41C24S4DTUZ&dchild=1&keywords=statistical+consequences+of+fat+tails&qid=1594856854&sprefix=statistical+consequences%2Caps%2C196&sr=8-1
• 15 July 2020: Yeah my first client projects were "37express" one-page redesigns.
• 15 July 2020: No special inside track. He liked the work and selected me into a final round of candidates. He asked each of us to do a one-week redesign of the Verizon home page, visual only (no code), and I won the job.
• 15 July 2020: 37signals' graphic and UI design POV was extremely differentiated at the time. I looked up to them and felt I was part of the same scene — because of matching tastes — even though I didn't know Jason. We were both in Chicago. He posted an opening for a web designer and I applied.
• 15 July 2020: 17 years ago Ruby on Rails didn't exist and I didn't know how to program. I learned so much looking over the shoulders of @bitsweat @sstephenson @packagethief and alums @jamis and @noradio . There's no better school than working alongside generous people who are ahead of you.
• 15 July 2020: Thanks Jamis! I learned a lot from you and your code.
• 15 July 2020: Hard to believe it's been 17 years. Owe much of that to @jasonfried and @dhh 's willingness to continually tweak my place in the org as my skills & interests changed. Each of these years has felt fresh, w/ new challenges, wondering "What can we do next?" https://twitter.com/dhh/status/1283497800009826304?s=20
• 15 July 2020: It's a question of what scale is right for what type of task. There are cases where large teams are effective. But not for making hard trade-offs. Those happen in small circles.
• 15 July 2020: Yes. Different scales are qualitatively different.
• 15 July 2020: More the latter.
• 15 July 2020: Throw out everything except for the top few things that are exciting or scary or puzzling and then work on those.
• 14 July 2020: Reps. Learning what it feels like to get stuck in different ways.
• 14 July 2020: Not important. I still keep trying different things. Maybe will land on something in the future.
• 14 July 2020: From a thread answering Qs about what a full-time shaper does every day and how to structure time and be productive in that role. https://twitter.com/rjs/status/1283137201719533568?s=20
• 14 July 2020: Note there's no "right path." It's about knowing where I am at a given moment and what space to move into to make the progress I'm trying to make.
• 14 July 2020: One example path from recent history: pic.twitter.com/yKKqQZhmlY
• 14 July 2020: Here's a map: pic.twitter.com/GapzQusRr3
• 14 July 2020: ... Struggling because I can't seem to shape it, or because I don't know how to shape it, or because I don't know what to shape. Those struggles cause the flips between forging/shaping or the moves up/down between project/portfolio scale.
• 14 July 2020: The hard deadline, of "I need to have something shaped for them to do by X" helps. It keeps pulling me back to the immediate scale of "which valuable project can I finish shaping soon." Everything else is a way to deal with struggling with that.
• 14 July 2020: I hope this gives you a sense of what it feels like to flip back and forth between forging/shaping at a project level, and to scale up and down between the project level and the portfolio level. Always letting my sense of what I don't understand being my guide for where to move.
• 14 July 2020: So I zoomed up a level to look at the portfolio again. Formed an opinion about what bundle of projects make more sense strategically and why. Then dove down into individual projects again.
• 14 July 2020: I've done both recently. Before kicking off BC4, I did a fresh round of customer interviews and analysis. Then for a while I had many separate project ideas in the portfolio. Shaped a handful... Then got lost because I didn't see how they added up to a coherent whole...
• 14 July 2020: If the problem is supply-side, I can reach for tools like interdependence diagram to see what to work on first and how they relate. If demand-side, I'll drop the projects and do a round of interviews to clarify our stance in the market.
• 14 July 2020: If I don't have a good portfolio of things to work on, or I don't know how to sequence work in the portfolio, then I ask: Is the problem supply side? Ie. I like the parts but can't see how they fit together. Is the problem demand side? Ie. I don't know what is valuable.
• 14 July 2020: I find it helpful to start from the small scale and work up. If I have an obviously valuable idea for a project in the next cycle, I'll focus on that. If I can't shape an idea, I need to forge it or switch to a different idea. That's a the project scale... then up a scale ...
• 14 July 2020: Since your question was very broad that's a broad answer. I can try to answer more specifically if you give some direction.
• 14 July 2020: Depending on whether it's in the "I'm still trying to figure out what the problem is" (forging) category or the shaping category, I'm going to reach for different tools, and the application of those tools is going to decide what a day looks like.
• 14 July 2020: I think it boils down to having a portfolio, and clearly labeling each thing in the portfolio in terms of how much I understand it. Is this notifications thing something I'm still trying to understand? Or do I understand the problem and I need to shape it?
• 14 July 2020: So what happens on a given day is constrained by what I'm trying to do at that higher level — either better understand some problem, or take something I think I understand and try to shape a concrete solution.
• 14 July 2020: What that means re: actual work is wide-ranging on the forging side. It could mean interviewing customers, it could mean looking at some data, or inspecting our own account. It could also mean just keeping it mind and waiting for something relevant to happen that sparks an idea.
• 14 July 2020: For example, I might develop some sense that there is a problem with notifications in Basecamp but I don't know what to do about it. I'll dedicate time in a cycle to trying to better understand the problem and figure out if there's something to shape in response.
• 14 July 2020: I have some high level goals at the scale of six weeks, to fit in with the cadence of the rest of the company. There are some big things I want to either learn about or try to shape. I've called those "forging" vs "shaping" in the past... still playing with those terms.
• 14 July 2020: Um, my first reaction is daily seems to be the wrong scale. Daily routine can mean getting distracted by some call, sketching for an hour, having a random conversation with someone, then doing a podcast interview.
• 14 July 2020: I would start with a very simple common-sense view... When we don't shape, we find ourselves getting lost or stuck and then wasting time. Because it's not clear what we're doing. So we carve some time to shape because the cost of that time is < the cost of getting lost/stuck.
• 14 July 2020: This depends on the scale of the org. At Basecamp's scale today I can forge and shape full-time, versus when we were smaller some of us would split time between shaping and building.
• 14 July 2020: The problem with big groups is you can't take anything away. Once something makes it onto the whiteboard or into the document, it becomes law. With tiny teams, you can scrap or wipe the board or take a hard right turn. That's what you need at the shaping/betting phases.
• 14 July 2020: To produce tight pitches with narrow scope, the team working on them must be small. Committees can't make trade-offs. From the Shape Up forum: https://discourse.learnshapeup.com/t/our-pitches-are-full-of-must-haves-need-help-to-convince-ceo-to-trust-the-teams/440/6?u=rjs pic.twitter.com/ELiEVRClRp
• 14 July 2020: No, I don’t track that at all and those don’t sound related to me. Google it.
• 14 July 2020: Just have to maintain certain level of humility and expectation ... probably there is a core that is unexplainable (per Gödel). Just trying to enjoy the challenge and hopefully it’s helpful for some similarly-minded people.
• 14 July 2020: Not sure I follow you, but no I don’t feel anything is lost. If anything, trying to explain while doing sharpens my understanding. I think Kent Beck’s work is a model example of this kind of activity.
• 14 July 2020: “How do you reconcile?” By careful observance of the use-mention distinction.
• 14 July 2020: /cc @bmoesta
• 14 July 2020: Getting closer to writing an accessible introduction to this topic. Then perhaps the tweets will become less cryptic. Interesting because it’s recursive: explaining system design requires designing a system of explanation.
• 14 July 2020: pic.twitter.com/xkXwTFtzCZ
• 14 July 2020: This is a case study of what I talked about in Ep 5 of Synthetic A Priori ( https://synthetic.transistor.fm/episodes/system-design-as-a-pattern-language-cognitive-grammar ) At one point I had S3 and S4 defined, not knowing if they were one thing or two. Decided: one. Together, they defined a semantic pole. Then named them. https://twitter.com/rjs/status/1282847517390954497?s=20
• 14 July 2020: Pattern 104 in A Pattern Language (page 508).
• 14 July 2020: Also shuffled things a scale down. Moved a subsystem of S2 ("Questions to ask") to S3. Interesting how this abstraction of system design seems to apply just as well to writing as to software development.
• 14 July 2020: A moment of system design. Identified four systems for a (possible) refactoring of Part 2 of Shape Up. That doesn't mean there are four chapters, though. Decided to chunk [S1, S2, S3, S4] as [S1, S2, S3 • S4] and name the third chunk "Place Your Bets." https://twitter.com/rjs/status/1282844029990744064?s=20
• 14 July 2020: Too brittle. The discussion could take a bad turn, or a better discussion could pop up later. Would rather extract good stuff from the forum over time into future editions.
• 14 July 2020: Setting a very tight appetite on this work because I don't want it to devolve into rewriting the book. If the new stuff doesn't snap together quickly (literally in a couple days) firing the circuit breaker and moving on.
• 14 July 2020: This quick scribble shows the thought process of figuring out what the chapters in the Betting part should "do." Approach A1 was to focus on the functional process of betting in an org. A2 was to focus on the process of explaining the concepts. Stopped when A1 seemed to work.
• 14 July 2020: Worked on a potential refactor of Part 2 (Betting) of Shape Up today, to create space to answer questions that keep coming up before we do a print edition. Applied Alexander's "site repair" pattern. Saw Ch 8 was kind of a junk drawer, so tried to fix it as part of the change. pic.twitter.com/lX0C3nPcmF
• 13 July 2020: Academic knowledge is not skill. Good discussion on EconTalk: https://overcast.fm/+JBsuLrk
• 13 July 2020: Short answer: Sounds like not enough horse trading at the betting table. Not about pitches or trust. If she doesn’t see trade-offs, she’ll naturally ask for it all. If someone she respects can point out trade-offs, try it. Otherwise wait for blow-ups to motivate change.
• 13 July 2020: Responded on the forum here: https://discourse.learnshapeup.com/t/our-pitches-are-full-of-must-haves-need-help-to-convince-ceo-to-trust-the-teams/440/2?u=rjs
• 13 July 2020: Such a powerful point: @DReinertsen subsequently explains that the purpose of “batch size reduction” is to generate feedback loops. Sprints don’t generate feedback loops when they are just incremental bites out of a bigger thing that you have to do! There’s no embedded option!
• 13 July 2020: Reinertsen perfectly explains circuit breakers in this talk at 39:14. “I’m giving myself a chance to shut down a bad option early ... to shut down that class of paths with as little investment as possible to end up getting the payoff.” https://www.infoq.com/fr/presentations/rethinking-robustness/ ? pic.twitter.com/isiEU9BSjX
• 13 July 2020: They choose.
• 13 July 2020: Right.
• 13 July 2020: The smallest appetite is one week. But important to point out that we don't schedule that as a week on a calendar. The teams figure out when and how to sequence that within the six weeks.
• 13 July 2020: Important point about Small Batch cycles (combining a few small-appetite projects into one six-week cycle). We don’t juggle them all and ship at once at the end. We focus and finish them one after the other. https://twitter.com/jasonfried/status/1282393213454692353
• 13 July 2020: Honestly, I think the key point is this ... We judge the cycles by looking at what ships. We shouldn’t judge cool-down time the same way. It’s not about shipping. More about learning, communicating, janitorial things etc.
• 13 July 2020: I’ve done Shape Up with small teams on side projects — people with literally only six weeks of experience after the first cycle. In my experience they were eager to use cool-down to improve that test or make that refactoring they had to hammer out from the cycle to ship on time.
• 13 July 2020: I haven’t seen any struggles with that myself. Seems that people usually have stuff they feel they should learn or something they want to fix etc.
• 13 July 2020: It can also happen that there’s less design work on this project than that one. The designer has flexibility to finish and move on to the next thing while programming is finishing something else. They’re still focused on finishing one at a time, but there’s room for overlap.
• 13 July 2020: Yeah, what Jason said. In the simplest terms, the teams do the small batch projects one by one. But you could ask: why not just schedule them one by one then? Putting them in a batch not only simplifies scheduling but also lets someone move on while waiting for QA, for example.
• 12 July 2020: Reinertsen’s work is good and, to the extent I understand it, aligns well with Shape Up.
• 12 July 2020: Interesting shift in perspective. “How long are we willing to wait to do X.”
• 12 July 2020: When you feel like you are spending too much time planning what to do and things aren’t getting done when you want them to get done.
• 12 July 2020: Yes. Eric Evans’ Domain-Driven Design made this point really well with the Ubiquitous Language pattern.
• 12 July 2020: Tufte’s work in Visual Display of Quantitative Information offers a way to think about this mapping, when he says that design choices enable different types of cognitive process. Eg some design choices make it easier to make comparisons than others.
• 12 July 2020: I believe we can use CG to describe how naming choices, copy and UI concepts are different from each other in terms of how they are perceived and what they evoke. But that’s a hunch. I haven’t done the work to do the mapping.
• 12 July 2020: It goes into a six week cycle along with other small work as a batch. Scheduling a few things without specific dates inside the time box allows them to slide around and adjust according to peoples’ availability. More discussion of that here: https://youtu.be/qkJJ9v4eryM
• 12 July 2020: This is a first attempt to start connecting the dots: https://synthetic.transistor.fm/episodes/system-design-as-a-pattern-language-cognitive-grammar
• 12 July 2020: If you have something important that needs a couple days, I don’t see anything wrong with calling that out formally. But that would be cumbersome to do often. That scale is down in the weeds.
• 12 July 2020: Yes the kick-off calls out the appetite for each project in the mix for that six-week cycle. We usually don’t formally schedule work smaller than one week. But since we have a rhythm and trust within the teams around all this, we may informally drop little things in.
• 12 July 2020: Yes. 6 weeks is different than 2 weeks plus 2 weeks plus 2 weeks ... https://twitter.com/adamwathan/status/1282311407850201090
• 12 July 2020: Yes DDD is a perfect example. Right in the center of all these topics.
• 12 July 2020: Fixed. Just missed a few words: "then 'chalk sharpener' eventually becomes part of our pattern language." New audio is swapped in now.
• 12 July 2020: @dvandelay Thank you. I’ll fix.
• 12 July 2020: Different itches getting scratched at different times.
• 12 July 2020: This one wasn't easy. But it does roughly accomplish something I wanted to do for a while: introduce Alexander's idea of pattern languages using his concepts of form and context (from Notes on the Synthesis of Form) as primitives. https://twitter.com/rjs/status/1282147014411612161?s=20
• 12 July 2020: ⭐️ Synthetic A Priori: Episode 5 On pattern languages and system design. Defining patterns in terms of form/context pairs. Speaking Basecamp's language. And taking a leap to link Christopher Alexander's work to Langacker's Cognitive Grammar. https://synthetic.transistor.fm/episodes/system-design-as-a-pattern-language-cognitive-grammar
• 11 July 2020: Yeah I ended up finding the Buddhist framework around all these things much more satisfactory and robust.
• 11 July 2020: (or what it is made *of, above)
• 11 July 2020: Impromptu microlecture thread on Kant's Critique of Pure Reason. https://twitter.com/rjs/status/1282077492434501632?s=20
• 11 July 2020: If that way of categorize stirs interesting questions for you as a curious person about those things, then that's I think the main function of his work. I don't believe he reached compelling conclusions. His contribution was this method of asking.
• 11 July 2020: He tries to orthogonalize knowledge along two dimensions: synthetic vs analytic, and a priori vs a posteriori. True from how it was put together or by what it is made up. And known in advance or known after experiencing.
• 11 July 2020: Is there something about the "way" things are experienced that is always true? And are things like mathematical truths more like the content of the Netflix show ... circumstantial ... or more like the RGB?
• 11 July 2020: Then he takes that principle and asks ... what things are like the former and what things are like the latter? This leads him down a path of asking if there's an equivalent to the RGB of our very faculty of experiencing things.
• 11 July 2020: Like, you can't derive from logic what will appear on a Netflix show. But you can say with certainty that whatever appears on the new Netflix show, it will be made up of little bits of red, green, and blue light on a 2D surface.
• 11 July 2020: Honestly even the summary versions are a slog. His key idea is to question what we know and how we know it, and separate everything into two broad categories: things that are circumstantial, and things that must be how they are because of some ultimate principle.
• 11 July 2020: It's a slog. I'd recommend some kind of cliff notes or intro or summary instead of going straight to the source on that one.
• 11 July 2020: Synthetic A Priori is a reference to Kant's Critique of Pure Reason.
• 11 July 2020: That's called building.
• 11 July 2020: Your piece was an exception to (c) and now here we are.
• 11 July 2020: Yes. Hoped to dismiss because: (a) in general I'm skeptical of the value of "note taking systems" (they all seem very high fuss, low-leverage to me), but it (b) kept coming up (yes around Roam), and (c) the links/articles about it looked complicated/opaque.
• 11 July 2020: I was hoping to continue dismissing Zettelkasten. Turns out I stumbled into that same hierarchical principle with immutable numerical labels + appending new labels w/ a hierarchy in the prototype shaping method I've been using. pic.twitter.com/z4bpCiyAq5
• 10 July 2020: Btw regarding topics of application, would love to explore a way to segment those that is situational and universal. Then use those more vertical areas as case studies. Eg help me recognize when to reach for which tool, regardless of domain.
• 10 July 2020: - Adjacent possibility - Generating vs specifying structure
• 10 July 2020: My #1 rec these days is Competing Against Luck to get started. I don’t know what little white book you refer to.
• 10 July 2020: Fantastic introductory lecture on Ronald Langacker’s Cognitive Grammar. Full of fascinating, very fundamental concepts. https://youtu.be/dDfX3971Z_A
• 10 July 2020: Of course, it has to actually be a struggle :) Just speculating about a struggle (“wouldn’t it be easier if....”) doesn’t work. We see a lot of that in the software world.
• 10 July 2020: Much of innovation (and product strategy) is about seeing as struggle what other people put up with as “normal” and doing the work to find a better way.
• 10 July 2020: Shape Up is also similar. People can feel that daily standups and sprint planning meetings and tickets are painful, but need to see an alternative for the light bulb to go off.
• 9 July 2020: Yes those are two different stages of the same process. When I have struggle but no light bulb, I don’t even think of an alternative. When I see the light bulb (better way), I might not switch immediately. But the tug of war starts between the old way and the new way.
• 9 July 2020: This is what’s happening with http://Hey.com among the early adopters. There was no “one thing” that was bad about email. The windshield was covered with bugs.
• 9 July 2020: Sometimes we endure the pileup of little struggles because we don’t know a better way. We live with it and even tell ourselves stories about why it has to be like that. When the better way comes, we suddenly see the contrast. “Oh I didn’t know!” And boom, a big switch.
• 9 July 2020: The little struggles are what @bmoesta calls “bugs on the windshield.” One by one, they don’t matter. But on second order they can turn into a push one day that leads to considering a change or switching.
• 9 July 2020: Just like big hires (purchases) and little hires (use events) there are big & little struggles. Big struggles have explicit pain. “The upload failed and I lost their audio track.” Little struggles are tacit pain that accumulates. “I looked there but I couldn’t find it.”
• 9 July 2020: These numbers are very likely goosed.
• 9 July 2020: Here's a list of early adopters: https://discourse.learnshapeup.com/t/experience-reports-before-and-after-shape-up/16
• 9 July 2020: Been talking a lot about thin-tailed vs. fat-tailed risk lately. For those wondering what those terms mean, here's a short thread to get you started. https://twitter.com/rjs/status/1281332902081396736?s=20
• 9 July 2020: In the context @adamwathan and I were talking about, the X was the time it would take to do something. Whether that X is thin-tailed or fat-tailed depends on the kind of work and unknowns involved in doing it. We want to identify them because they pose different levels of risk.
• 9 July 2020: Those different kinds of unknowns are described by different "probability distributions" — mathematical things with different shapes. The "tail" is an aspect of the shape. That should give you enough intuition to learn more independently.
• 9 July 2020: Those terms come from probability theory. Basically take some number X that is unknown. If you were to guess X, how wrong could you be? Thin-tailed is like height of people: Nobody is 10x taller than anyone else. Fat-tailed is like wealth of people: Some are 1000+x richer.
• 9 July 2020: Any Shape Up adopters want to raise their hand on this thread? https://twitter.com/bradenbhs/status/1281317838272299008?s=20
• 9 July 2020: I don't have a definitive list. I've heard from dozens of companies so far. From tiny startups to Fortune 50.
• 9 July 2020: The point is that if you don’t know how to untangle, there is a lot of risk. So the untangling should happen in the shaping phase. Spike to learn the tangle and design a solution, then bet on the solution.
• 9 July 2020: You can’t get very far on paper. Straight to code is better. But there is some art to sequencing the unknowns so what you build is teaching you and you aren’t throwing too much away.
• 8 July 2020: Then, after the bare tentpoles of the core architecture are worked out, you have a reliable structure that everything else hangs off of. This is where the shaping/betting/building cycle starts, where you can set hard expectations about what will be 100% done at the end of cycles.
• 8 July 2020: The approach in R&D mode is fire a lot of “tracer bullets” in @dhh ’s terminology (goes back to Prag Programmers I think). Build a few what you believe to be core pieces half-way until you gain confidence that the tentpoles hold together. Accept scrapwork and surprises.
• 8 July 2020: If you don’t have a core architecture for the product yet, that kind of restart is actually to be expected. You can’t reliably shape until you have a core architecture to shape “into.” We call this R&D mode at the start of a new product. We expect a lot of scrap.
• 8 July 2020: That’s a broad area. Can you tell me about the context of what you’re trying to do?
• 8 July 2020: New unknowns aren’t going to appear in the code unless somebody changes the code. Or ownership of a piece of code moves out of our control.
• 8 July 2020: Practically speaking, for normal software development, we can/should treat the code as known. It’s committed. It’s there in the repo. It doesn’t change unless we change it.
• 8 July 2020: This post doesn’t address what I believe is the key point: that the distribution is determined by the structure of the problem. The way that we design the problem and place bets actually changes the distribution of the time-to-ship variable. That’s what Shape Up is all about.
• 8 July 2020: The number of dependencies is scale bound. I could say “updating subscriptions is easy. we’ll just call to the API.” One dependency! But if I don’t actually know what the API does or whether it does what I need, there’s opacity there. Zoom in, and there are many smaller deps.
• 8 July 2020: See answers to this: https://twitter.com/jensbackbom/status/1280978933350006793?s=21 https://twitter.com/jensbackbom/status/1280978933350006793
• 8 July 2020: But yes, past a certain point of complexity, there’s an unavoidable risk of being wrong. That’s why we have “circuit breakers” on bets in Shape Up. We assume that even after all our efforts to reduce risk, we still might be wrong and need that protection.
• 8 July 2020: Distributions aren’t random. They come from the underlying structure of the system. If the underlying system isn’t opaque, you can judge the distribution. Some systems or subsystems are simple enough to understand.
• 8 July 2020: In theory, that’s true. Like how a fat-tailed distribution can look thin-tailed because you can’t get enough observations to see the true properties. In practice, not always. When you see all the moving parts and dynamics, you see the process that generates the distribution.
• 8 July 2020: All of these examples should how we derive the estimate of how bad the blow-up can be by looking more closely at the kinds of things we don’t know and how those unknowns are related to each other as a system.
• 8 July 2020: By reading up on the docs, talking to the provider of the 3rd party API, spiking a solution, we can get to a point where we have a small number of isolated unknowns again. Then our updated model of the connections gives us a thin tailed risk.
• 8 July 2020: What if the action of the button is supposed to change a subscription, but we don’t control or understand the 3rd party subscription management API? There are multiple unknowns connected in a chain. -> Fat tailed distribution. Could take 10x or worse longer than we think.
• 8 July 2020: Examples: What’s the copy on the button? Completely independent. Bounded.. -> Thin tailed distribution We need to define a color for primary action buttons. Slightly dependent (on other colors in the scheme). Bounded. -> Thin tailed but wider body. (cont...)
• 8 July 2020: The question is, given a naive estimate (x days), how much error should I expect? Different distribution can mean orders of magnitude more error (ie takes 10x longer than we thought).
• 8 July 2020: WIP on how to look at unknowns: 1st order: - Bounded: I don’t know the answer but I know some combination of the pieces I have will work - Unbounded: I don’t know the answer and I don’t know if I’m missing a piece or not 2nd order: - Does this unknown depend on other unknowns
• 8 July 2020: Been finding it very profitable lately to think of probability distributions not as dice-rolls, but as degrees of freedom afforded by the causal structure of a system. Concretely: To estimate the riskiness of a project, we look at how the unknowns are connected as moving parts.
• 8 July 2020: Importantly, spikes answer the “is there a straight shot?” question not with a yes or no, but with proof. The answer is the spike itself — a few bits of code that demonstrate how wiring A to B to C does what you hoped.
• 8 July 2020: From Extreme Programming and/or the culture around that.
• 8 July 2020: The other outcome that isn’t a “straight shot” is where you walk into a fog. You can’t tell if it’s a tangle or not. But you can’t see the end. That’s like if there’s some interdepency with a system you don’t understand or don’t control.
• 8 July 2020: The opposite of a “straight shot” is a tangled web. That’s where you pull the string and you go “uh oh, this also touches this other thing ....” and before you know it you have to rewrite a whole chunk of the system to get what you want.
• 8 July 2020: When we spike, we’re often asking ourselves one question: “Is there a straight shot?” A straight shot is a picture of what we need to do that involves a small number of moving parts, a small number of interdependencies, and clear stopping points.
• 8 July 2020: When we interview, we know that we are just learning. Same with spiking. The output isn’t necessarily code to commit. The output is knowledge of (a) what moving parts are involved, (b) how they causally relate to each other, and (c) where the edges are and whether it stops.
• 8 July 2020: Pulling on this string the last couple days... When there many unknowns about the feasiblity of a project, we do a spike to learn. This is like interviewing on the demand side. When we don’t know what the variables are, we interview. Spiking is like interviewing the code base.
• 8 July 2020: First start by reading Competing Against Luck by Clayton Christensen. If that clicks, next step is to learn how to do the interviewing. Can either do a live workshop or online course. (Something like http://learn.jobstobedone.org/courses/JTBDinterviews or watch for an event with @bmoesta .)
• 8 July 2020: @Legrigeois_L Great question. We only make bets on pitches at the 6-week cycle scale. At the scale of 2-3 cycles we have ideas about what might be priority to do, but no actual sequence or shape. At ~1 yr scale, we have ideas of which product to focus on, directional ideas, but no details.
• 8 July 2020: UI is like code. It's just how you implement a product idea. You don't say "this code was inspired by a user interview." Wrong level of description.
• 8 July 2020: We has already hacked Basecamp to work that way for ourselves, but didn’t see that this applied to customers more broadly until we did the interviews. Saw a substantial uptick in consumption after making the change.
• 8 July 2020: You asked for an example. Splitting Basecamp’s projects into three types—HQ, Teams and Projects—came from doing JTBD. We learned people were using Basecamp to improve communication across the company, not just for projects.
• 8 July 2020: Interviews are the flashlight I reach for when I am in the dark. Sometimes we already have plenty of ideas of what to do. No JTBD needed. But if I don’t understand an area I’m working on, I’ll do interviews to change that.
• 8 July 2020: Exactly.
• 7 July 2020: Lots of it is about helping them get back into the moment. They say they signed up a month ago. “Where were you?” “What else was going on?” “Was it before or after lunch?” And click click click it comes back.
• 7 July 2020: I learned interrogation techniques for this purpose. Ask for specifics. “Wait, that doesn’t add up.” “If that was true, why didn’t you X?” Etc.
• 7 July 2020: This relationship is roughly logarithmic, not linear. That is, the time scale doesn’t need to be very long before you have to plan very abstractly. We only plan concretely six weeks at a time. Plans longer than that already must be very abstract.
• 7 July 2020: The longer the time scale, the more abstract the plan has to be.
• 7 July 2020: There’s a space view of what the use “has” and a time view of what the user does and experiences. Ditto building. Space view of the structure of the system and time view of creating that structure.
• 7 July 2020: I was originally thinking of two head spaces that I flip between, all supply side — shaping, betting, building. You’re right ... this flip is equally important demand side. Essential to look dynamically at the process the user is within to get the requirements for the structure.
• 7 July 2020: Your pushback makes me want to use different terms. Forget “space” and think “structure” instead. The distinction I’m trying to make is between structure and process of creating the structure.
• 7 July 2020: Yes what the user is trying to do is the main requirement for the system design. The system does what the user needs. There’s no separation there.
• 7 July 2020: Example of "how I use my time to produce the system" — the sequence of problem solving. Or when to do research or experiments. Or how long I give myself to work on a given piece. These are all time questions.
• 7 July 2020: To your example, for me the meaningful question is .. how do I get that experience to "compile" in the audience's mind so it's the best possible given my constraints. Doing that involves designing both the system and how I use my time to produce the system.
• 7 July 2020: Good to contextualize this. All of this is from the builder's perspective. From the builder's perspective, the time experience generated by the product has to be caused by the design of the system. That system is static (some code in a repo, a building standing, a .mov file).
• 7 July 2020: Basecamp's books are products of working "on" the business not just "in" the business, a good portion of the time, for over 20 years. https://twitter.com/rjs/status/1280624219139633153?s=20
• 7 July 2020: Wonderful distinction from a convo w/ @bmoesta just now. Working "in" the thing vs working "on" the thing. Eg. building a project with our team vs. redesigning the way our teams build projects.
• 7 July 2020: These are very different things. That's the distinction that I'm talking about. The structure of a thing vs the evolution of the thing.
• 7 July 2020: The "time" aspect I keep referring to in my mind is about how things unfold from the perspective of the builder. The director/editor/team works through time to ARRIVE at the 90 minute film. The film time != the problem solving time and production time.
• 7 July 2020: No. For me this points to a delicious subtlety in this way of thinking that I'm not good at communicating yet. Time as designed into a system is part of the system. A 90 min film takes 90 minutes. That's all part of the space of the system — its static structure. The .mov file.
• 7 July 2020: Or another example, the percentage of customers who have more than 25 projects in Basecamp is a space-like view. It reflects a static fact. The story of how one customer gets to 25 projects is a time-like view. It reflects dynamics.
• 7 July 2020: For example, if I'm designing a presentation... Number of slides, arrangement of topics, content is the "space" aspect of the problem because it has to do with the static structure (saved in the file). Amount of time I carve to create it, process I use to solve, is time aspect.
• 7 July 2020: First attempt to talk about it is here: https://synthetic.transistor.fm/episodes/walls-in-space-and-time-system-vs-parameter-design Very rough still. Basically, two very different views on a system. Space = the static structure Time = dynamics of how things unfold and change
• 7 July 2020: The context I’m talking about is a big presentation from one person to 200+. It works like you say with small groups.
• 7 July 2020: Relevant: https://twitter.com/rjs/status/1280569578897039361?s=20
• 7 July 2020: I use qualitative research intensively. It's my number one research tool. The key point is I don't ask people for their thoughts. I ask people to describe their past actions, and then ask for the thoughts they had when deciding in the past. Very different.
• 7 July 2020: Huge difference between "what stood out when you first opened the trial?" vs "what do you like about Basecamp?" The former is embedded in a context and a shopping process. The latter doesn't map to a design problem.
• 7 July 2020: Imo asking people for their thoughts in the past when they were in a process of making a decision is extremely valuable. Because those thoughts were causal to their behavior. Asking for thoughts reflecting on things isn't valuable for design purposes.
• 7 July 2020: "Do data" — nice.
• 7 July 2020: Impossible.
• 7 July 2020: I don't really want to know what people "think" when it comes to tuning an offering (product, book, presentation...) I want to know what works. I want to know what effect it has.
• 7 July 2020: People who are in direct confrontation with what works know this. Stand up comics don't send feedback surveys. Musicians don't send feedback surveys. They know the laugh or the moving body is the truth.
• 7 July 2020: Important to distinguish: Asking people their thoughts on something is not feedback. That's an invitation to make up stuff. Real feedback is action — facial expressions, laughter, turning away, agreeing, hesitating, buying, leaving. Everything else is a suspicious imputation.
• 7 July 2020: I'm talking about immediate feedback. We get it for free automatically whenever we talk to somebody and can see their face.
• 7 July 2020: Dig the idea of starting with low-cost options like that. Reminds me of Taguchi's thing about seeking quality with new combinations of the components you already have instead of adding in more expensive parts.
• 7 July 2020: Of course. That's part of the information.
• 7 July 2020: When we first start speaking, it's hard to look at the audience cuz we are preoccupied in our heads. Once we get more practice, we can look at their faces while we talk without getting thrown off. When you see their faces, it's obvious.
• 7 July 2020: 100%
• 7 July 2020: Yes. That's the kind of thing to take as a starting point. Start in the tails of new interesting things not the body of status quo that nobody likes anyway.
• 7 July 2020: The standard "talk at a conference" setup with canned talk and slides is artificial and strange. I wouldn't design around it.
• 7 July 2020: IMO it's much more simple. Every decent school teacher does this. They don't follow a linear script for the whole day. They intervene and react based on what the students are doing.
• 7 July 2020: Depends if contributing is done passively (just by being there and others see you) or actively (by pushing buttons, etc). Also can depend on whether the feedback loops back to audience members. There's value to seeing how people around you are reacting to something.
• 7 July 2020: Interesting angle. Ideally whatever the mechanism is, it would be transparent to each audience member so they would also know what is being seen and what they're broadcasting out to the speaker. Need that feedback loop for behavioral reasons and ethical ones too.
• 7 July 2020: The best speakers are more like standup comics. They are part of the living situation and adapt to what resonates and what doesn't.
• 7 July 2020: As a speaker I'm not interested in votes/polls. I want direct live feedback that tells me what's hitting and what's not.
• 7 July 2020: Interesting point about feedback loops. We behave differently when people can see us and we know they're seeing us. For the audience member, the existing tooling signals that nobody is looking at them so there's no reason to adapt behavior.
• 7 July 2020: Surveys, in general, are uninformative. Need very special conditions wrapped around them to be useful. Also, boring. Want to know what hit in the moment so I can learn and adapt at a muscle level.
• 7 July 2020: This idea that it's normal to anonymously lurk on a live event does not need to be normal at all. This is just historical accident that we are starting at this point.
• 7 July 2020: Opportunity to set expectations for specific events, just like in real life. You are showing up to a public space. Dress and act accordingly.
• 7 July 2020: Oh re: the PIP. I see what you mean. May be different if it's just visible to the speaker (who can see everyone from their vantage point in real life anyway) vs being re-broadcast to audience. I was thinking just speaker.
• 7 July 2020: Imagine if those were explicit. And you had different tools or links to either "sit among the live audience" or "sit behind glass anonymously."
• 7 July 2020: There is lots of room to play with defining these expectations. When you join a talk in real life, you dress and behave a certain way because you know other people will be there with you and see you in the audience. Today we don't distinguish lurker-vs-public attendance.
• 7 July 2020: https://twitter.com/rjs/status/1280549607819243520?s=20
• 7 July 2020: Example ... Japanese TV has this convention of showing audience members picture-in-picture. Even randomly doing this more often, cycling between lots of people, could be effective.
• 7 July 2020: Well said.
• 7 July 2020: Something about requiring the attendees to do something explicit feels wrong to me. My intuition is the problem is more about how to create a circumstance where their natural attitude becomes visible.
• 7 July 2020: That's an example of thinking of this as a scale transformation problem. What information could I give up at micro to gain at macro when absorbing all the micro information (200+ camera feeds) isn't possible. Could be wrong, bad ... just an example of thinking it through.
• 7 July 2020: I'm looking for something more direct and dynamic. Random super-wild exploratory example: update the clients to require video of every attendee, use ML to detect their eyes, crop out those slices, and assemble them into a big mosaic on display for the speaker.
• 7 July 2020: The biggest gap in virtual conferences: lack of feedback. This is an area to try and innovate in. After/while giving a talk, there's no way to tell if the audience is sleeping or fascinated or skeptical etc. Need some kind of follow-up process or new signaling mechanism.
• 7 July 2020: Good observation. It’s easy to overindex on the form of a deliverable and underindex on the process that generates it. (This is another “space” vs “time” thing, btw.) https://twitter.com/okdan/status/1280527266221420544?s=21
• 7 July 2020: Thinking of exploring the connection between system design, pattern languages, and a bit of Ronald Langacker’s cognitive grammar on next week’s episode of Synthetic A Priori.
• 7 July 2020: Nice summary of the shaping process made by a reader on the Shape Up forum (see https://discourse.learnshapeup.com/t/shaping-process-visualised/420?u=rjs ) This reflects v1. Hoping to expand more on epicenters in the “rough out the elements” phase and better formalize the de-risking section. pic.twitter.com/sB8fgHFSWj
• 7 July 2020: No, private call. If we can make it more concrete we’ll do something public.
• 7 July 2020: Had a deep convo with @chriscbs today on how to help teams who struggle with the de-risking part of shaping because of opacity in the code base (eg. confusing legacy code). Interesting possibilities brewing to better define that step and introduce more accountability.
• 5 July 2020: Cool and, if you were the decision maker, curious what you hoped was going to be different going into the change.
• 5 July 2020: Subtle but important: time walls are about time to produce, time to solve. Not time for the user to experience.
• 5 July 2020: Number of slides is a space wall. That’s the design and scope of the system. Time wall is about time you allow yourself to produce the slides, regardless of number.
• 5 July 2020: Tangent but curious: Now that you’re on Notion, what‘s gotten better compared to being on Basecamp before?
• 5 July 2020: Chapter 11
• 5 July 2020: At Basecamp we track the work for the project exclusively with to-dos in the project, not using any other issue tracking system.
• 5 July 2020: https://basecamp.com/shapeup/3.4-chapter-12
• 5 July 2020: Very glad to hear that came through and thanks for giving it a close listen. This episode was a challenge for me. Still finding my way through the language for these things.
• 5 July 2020: Getting into Hill Charts opens a door to a deeper level of work. Challenges can come up along the way. They raise questions about where the interdependencies are and how to draw boundaries. Let me know if you ever need any tips. I’m trying to learn how to explain it all better.
• 5 July 2020: Yes. This is the point. Not to follow a method but to improve our understanding of what is what and where we stand at a given moment in a problem. https://twitter.com/garrettqmartin/status/1279791940570165250?s=20
• 4 July 2020: ⭐️ Synthetic A Priori: Episode 4 Walls in Space and Time, System vs. Parameter Design Drawing connections between shaping, Taguchi methods, and Kauffman's concept of work-constraint cycles https://synthetic.transistor.fm/episodes/walls-in-space-and-time-system-vs-parameter-design
• 4 July 2020: Likewise!
• 4 July 2020: I'm not making any claims about how kanban can or can't be used. I also recommend kanban in certain cases. My point was, the conversation you commented is meant to belong in a certain specific context.
• 4 July 2020: Completely different context. We’re talking about working inside of a fixed time box, not just taking things as they come with no end in sight. All details and context here: http://basecamp.com/shapeup
• 4 July 2020: Shaping is what reduces the anxiety. You don’t put a deadline on something until after you’ve worked out the most important points. Then it’s not worrisome, and the deadline just helps you to trim and cut the unnecessary details.
• 4 July 2020: Simply discipline. Bleed into cooldown is a slippery slope. Need to keep the time wall solid with no holes for it to motivate everybody to collaborate on making trade-offs and scope hammering inside the cycle.
• 4 July 2020: We do separate projects, so each one gets its own hill chart. That way we can evaluate the status of each project separately and there’s plenty of rooms for the to-do lists to stretch out as tasks are discovered.
• 4 July 2020: Always love the hard questions. Thanks.
• 4 July 2020: Yup that’s understandable. Comes down to trade-offs. The original issue was about design/dev overlap time. The Small Batch approach gives more freedom for handling odd overlap but at the cost of fuzzier micro-deadlines inside the cycle.
• 4 July 2020: If I’m two weeks into a six week cycle, I can feel the squeeze. I can’t feel anything 8 weeks into a 52 week year.
• 4 July 2020: Time scales are qualitatively different. You can’t make adjustments at the scale of a whole year. It’s too big and fuzzy. Within a six week box, you can actually feel the size of things and move them around. It’s a kind of natural horizon. Can only see so far.
• 4 July 2020: It may partly be about developing scope hammer habit, and especially finding the joy of hammering. That’s where marking stuff with the ~ for nice-to-have feels like a celebratory moment cuz you just got closer to shipping.
• 4 July 2020: But the time’s not there — other stuff is in the box too!
• 4 July 2020: Now that we’re spelling this out more, I’m curious so see what other peoples’ experience is. Need to run more trials to get confident that the bottom up “just works” given reasonable shaping to the appetites. What I’ve seen so far makes me optimistic.
• 4 July 2020: (Parkinson’s Law returns at the end of the cycle in the sense that they can fill in any remaining time with the things they flagged as nice-to-haves.)
• 4 July 2020: No, we haven’t had any pattern of problems with teams not shipping that would motivate us to try to do that. We see a weird kind of reverse Parkinson’s Law. The teams scope hammer agressively to the smallest possible version in a Small Batch context. (Good shaping helps.)
• 4 July 2020: (And of course ... as we talked about, the extra freedom of movement in micro gives you better odds of hitting the target at macro because there’s less waste.)
• 4 July 2020: It’s not as strict from the outside as creating a hard 2-week timebox. But that’s the scale trade-off! You give up some control at the macro to get more freedom to adjust in micro. The teams get a feel for it.
• 4 July 2020: By discontinguous I mean you can say “the appetite is 2 weeks” but the actual bottom-up scheduling inside the cycle may shake out as 3 days here, switching tasks while waiting for the designer on something, then another 4 days here and 3 days there.
• 4 July 2020: 1st answer above on your original tweet. 2nd, more detailed, answer: you still have appetites for each project. The appetite is the intended deadline, not containing cycle. Slightly less obvious b/c the work can be discontiguous in the cycle. But same as scopes in Big Batch.
• 4 July 2020: Short answer: it’s not meaningfully different than the challenge of scope hammering a big batch project. A big batch is “one” project, but it’s made up of more individual scopes (in the scope-mapping sense, Ch 11). Each one needs to be hammered as you go to reserve capacity.
• 4 July 2020: The projects don’t all ship together at the end. They ship as they’re finished. People like shipping. It boosts morale and removes weight from our shoulders. Inventory is bad. So team members are encouraged and naturally ship each project as early as possible in the timebox.
• 4 July 2020: Counterintuitive but essential point: 2 weeks + 2 weeks + 2 weeks != 6 weeks. Need fluidity. Room to shift to working on this while waiting for that. Putting three projects into a bigger time box, with team members arranging their own schedules, allows for that.
• 4 July 2020: It’s too hard to micromanage how much a designer is needed on this project vs that project and put it into a fine grain schedule. Instead, pick a few things that can all surely be done before the six weeks. Let the individuals involved sort out the timing. Scale transformation.
• 4 July 2020: Big a-ha on the livestream today. “Small Batch” is underexplained in Shape Up. Say we bet on 3 2-wk projects. We mix them in one 6-wk timebox. No schedule finer grain than that. Why? Fine-grain schedules blow up. Gives room to self-organize overlap/collab between team members.
• 3 July 2020: Good summary in this thread. https://twitter.com/parkermalenke/status/1279140377379786752
• 3 July 2020: I'm going to be doing more of these. If you want help on your team's Shape Up implementation, come on a livestream with me. We'll talk about your org and how you got to where you are, then debug whatever questions you have. Write ryan@basecamp.com. https://twitter.com/adamwathan/status/1279097760520830976?s=20
• 3 July 2020: This went way deeper than I expected. @adamwathan shared tons of details on growing his small team at Tailwind. And we got into a whole area of Shape Up that isn't covered in the book at all — how/why to batch small 1-2 wk projects into larger cycles. https://twitter.com/adamwathan/status/1279097760520830976?s=20
• 3 July 2020: We're live https://twitter.com/rjs/status/1279081461824409606?s=20
• 3 July 2020: I believe what’s controversial isn’t the content, it’s the insistence on rigor. All this stuff about expected utility never made sense. Anyone who’s been using it / pursuing it must have built up some immunity to rigorous truth and even the smell of truth.
• 3 July 2020: Going live in one hour to talk w/ @adamwathan about challenges adopting Shape Up on his team. https://www.youtube.com/watch?v=qkJJ9v4eryM&feature=youtu.be
• 2 July 2020: In practice this means: when somebody says “we need feature X” we say: 1. Show me the path that breaks down without X 2. Let’s see if that path is a dirt road, side street, or main highway
• 2 July 2020: Understanding path-dependence is the antidote to feature bloat. We can know which few things must be there as stepping stones to make the progress instead of casting a wide net with fingers crossed. #ergodicity
• 2 July 2020: This distinction may sound a little subtle, but it has been absolutely top of mind in every project our teams have built since v1 of Basecamp Classic. That’s why it’s in Getting Real as “epicenter design.”
• 2 July 2020: ... or more directly to your point, the sequence of use is also a product of the design process. It’s part of the solution. The point is the order of things we choose to solve is a different thing than the way people use the solution we come up with.
• 2 July 2020: Yes. The design of the solution and the path you take to design the solution are two different things. I’m talking about the latter. Of course the sequence of use is a requirement for the design.
• 2 July 2020: “centrality” — useful term here. Yeah.
• 2 July 2020: Path of solution != path of application https://twitter.com/rjs/status/1278823432419815424
• 2 July 2020: Distinguishes path dependecy of use from path dependency of design. User needs “log in” first to do anything. But that doesn’t mean I need to build “log in” first to solve my design problem.
• 2 July 2020: More formal take on “epicenter design” from Getting Real: The path you take to use a thing does not map to the path you take to solve the design of the thing. To use, you log in, land on home, navigate to project ... post a message. To solve, you don’t build log in first!
• 2 July 2020: Got a reference for that, for comparison? Key thing here is looking at causal relationships between parts: what’s a cause and what’s an effect in the process of solving.
• 2 July 2020: Need a little help rigorizing this ( @normonics ?) but there is something struturally going on where the nodes with more outgoing connections live on a different plane, an order higher, than the ones with incoming connections. To solve the whole system faster, jump from hub to hub.
• 2 July 2020: This is why I love Twitter. Can test a brief explanation of something and get questions right away that point out things that weren’t clear. Leads to a more robust explanation next time. https://twitter.com/bulatwit/status/1278816419677945862
• 2 July 2020: Also in this case I didn’t sequence S2 because it’s already solved. I’m using the tool to sequence unknowns.
• 2 July 2020: *no outgoing arrows
• 2 July 2020: Because S6 is an effect, not a cause (not outgoing arrows). The idea is to solve the key points that have the most outgoing arrows. Not to chase one local area down to the bottom.
• 2 July 2020: Very good programmers/designers do this instinctively. They hold a bunch of pieces in their heads, are aware of a kind of web of dependencies between them, and pick out a few key areas that have the most influence on the whole to tackle first.
• 2 July 2020: This is actually the same as “mapping scopes” in Shape Up (Chapter 11), but slowed down, spelled out in more detail. Differences: - Rather than asking what’s orthogonal we ask what’s dependent. Orthogonality shakes out at 2nd order. - We get not just boundaries, but sequence.
• 2 July 2020: Been reaching for this tool lately: the interrelationship diagram. When work gets tangled w/ too many moving parts. Brain dump pieces of the system, then 1. Arrange in a circle 2. Draw arrows A→B when solving A makes solving B easier 3. Follow outgoing arrows to sequence pic.twitter.com/PX66EK7jWf
• 2 July 2020: In other cases, what you learn conflicts with what you know about other use cases in the same feature area. Some Qs can help: 1. Is one a better fit knowing the higher-level job? 2. Is one more aligned with our supply-side values/opinions? 3. Do we need to size this to decide?
• 2 July 2020: A word for that is "sizing." Now we've seen this ... how many other people are in the same boat? Depends on the case. Because it's cause and effect, sometimes you can play it through and there are no other ripple effects or trade-offs. Just "ah ok now we get it." (cont..)
• 2 July 2020: Thread on using JTBD interviews for finer-grain things than "why did they buy?" Goes into how we do "support sleuthing" at Basecamp to better understand feature requests. https://twitter.com/rjs/status/1278731449835741184?s=20
• 2 July 2020: A word for this is "bracketing." You bracket out what you supposedly know (eg the customer's request or suggested solution) and go in blank. The only certainty is there was a problem and they wrote a ticket about it at this day and time.
• 2 July 2020: Yes. The way we think about it is ... The support ticket is proof of a struggle. It's saying "there's a story here." But we don't know what it is until we actually dig to get the chain of cause and effect.
• 2 July 2020: Any novel behavior has a timeline and forces. It's a general framework for the causality of decision-making. Not just tied to purchases.
• 2 July 2020: We do this often with what we call "support sleuthing." Someone writes a feature request. Somebody on our team asks them to do a short interview. They get the timeline and forces leading up to the feature request. This gives us the "real story" of what they're trying to do.
• 2 July 2020: Example of a more specific question: What's going on when somebody adds a Basecamp to-do from their phone? We can take that act as the "purchase" and then dig for the timeline and forces around it. This can give us context for design decisions then.
• 2 July 2020: The purpose of a JTBD interview is to figure out the cause-and-effect, the "how it works" of somebody using something. That can be high level of purchase or fine grain of when do they reach for this feature vs. that feature.
• 2 July 2020: This is probably the key point of demand-side JTBD interviews. The output of the interviews is not just "answers", but the actual variables. We dig out the variables that mattered in the cause-effect chain of each story and then aggregate them. https://twitter.com/rjs/status/1278729188791341056?s=20
• 2 July 2020: Here's the data from this project. The columns are outputs from aggregating the interview data, not pre-determined questions. pic.twitter.com/eO6FDiaucn
• 2 July 2020: You don't go into a JTBD interview with questions (variables). The interview is what gives you the variables. The purpose of the interview is to figure out what variables matter to explain the cause and effect.
• 2 July 2020: This is an example of using jobs-to-be-done in a targeted way. A question comes up that is hard to answer, about some trade-off on the supply side (what to build/offer). To decide, look at the demand. Use what people are trying to do to define fitness between supply/demand. pic.twitter.com/QEBciCniTE
• 2 July 2020: For programming simulations, all the value is in the basic setup. Show me what to install, how to get it running, and how to do a sample simulation. That hump is so hard to get over by yourself, and you often have questions along the way.
• 2 July 2020: Heard stories about people staying up late to do the catch-up for especially demanding sections. That part wasn't a good fit. For example: learning network concepts is very valuable. But implementation details of Erdos-Renyi, too much.
• 2 July 2020: Why gentle math? When you map it back to those purposes, you don't need much math. (1) is more about learning tools. (2) a little math can frame new ways of thinking. (3) doesn't require math. When math is too demanding, people have to flip from doing 1-3 to playing catchup.
• 2 July 2020: Did qualitative research on this for NECSI once. Three reasons people went to the course: 1) Give me hands-on skills to increase my opportunities 2) Give me new ways to think about my problem 3) Stimulate me when I need a break from normal work At maximum, gentle math.
• 1 July 2020: And here’s the YouTube link to put in your calendar for Friday at 11am Mountain Time: https://youtu.be/qkJJ9v4eryM
• 1 July 2020: Q: Given variable scope ... do you ever revisit pitches vs. the work that got shipped in the end? Do you track the gap? Answer on the forum: https://discourse.learnshapeup.com/t/when-a-build-cycle-ends-do-should-you-take-stock-of-the-outcomes/412/3?u=rjs
• 1 July 2020: Doing a livestream Friday Jul 3 at 11am Mountain Time w/ @adamwathan . We’ll be talking about his experience adopting Shape Up and I’ll answer questions. Link/Details TBA.
• 1 July 2020: Regarding user research, whatever research we do — whether scratching our own itch, or interviews, or observational — is an input to shaping. This is a very different POV from standard practice. We don't test on users. We understand the situation first and design against it.
• 1 July 2020: Shape Up is about how to ship on time, not about how to do the best thing strategically. The reason we focus on technical risk in the de-risking step is because misunderstood interdependencies can make projects go 2x, 3x, 10x too long. pic.twitter.com/jMBnMY2TzT
• 1 July 2020: We always work in six week cycles, no matter what kind of work it is. See this thread for three stages of cycle work that happens when building a new product: https://twitter.com/rjs/status/1259338296171192321?s=20 https://twitter.com/rjs/status/1259338296171192321
• 1 July 2020: We “ship” internally: merge the code to master, consider it done, and don’t allocate time to touch it again unless we make a new specific bet.
• 1 July 2020: Notability.
• 30 June 2020: Not a fan of the new iPad case. When you want to draw, the whole case sits awkwardly like this in front of you. The previous case flipped around and disappeared under the iPad. The Pencil, iPad, and new case don’t make a coherent whole. Hope they’ll course correct. pic.twitter.com/xGh9rAQ1j1
• 30 June 2020: Jason and I are speaking at the virtual INDUSTRY conference in September. Knowing @belsito and team, they're going to raise the bar for remote conferences. https://twitter.com/belsito/status/1278038749075693574?s=20
• 30 June 2020: Depends on scale and maturity of the project. I use Heroku for my small side projects because it's such a no-nonsense straight shot, esp for Rails. We use AWS at Basecamp, which is a totally different world of scale. (I don't have first-hand experience with AWS.)
• 30 June 2020: This ties back to the discussion around branding a week or two ago. Preference can maybe be viewed as a field effect of circumstantial decisions over time. All cause and effect.
• 30 June 2020: More specifically, a drastic enough change in circumstance can unseat a habit.
• 30 June 2020: Yeah. There’s probably a multi-order thing going on, where preference at 1st order should be understand as decision under circumstance (with null model for decider), but at higher order past decisions do bake in as habits. Key is to never lose the 1st order. Even habits change.
• 30 June 2020: Lots to unpack there.
• 30 June 2020: "Dig deeper and learn more on their own" corresponds to "active looking" on the buyer's timeline.
• 30 June 2020: Suspect this is generally true for marketing in the lead-generation stage (aka "passive looking"). https://twitter.com/rjs/status/1277981353670148098?s=20
• 30 June 2020: The goal in a conference talk isn't for everybody to know everything about Shape Up. The goal is to connect problem and solution so they can see for themselves if and how Shape Up could help them. After that, they have what they need to dig deeper and learn more on their own.
• 30 June 2020: Just gave a 30-minute talk on Shape Up at @9punto5_ . Spent at least 1/3 of the time on problem definition. Good to remember: people can't value what we tell them without motivation. More important to wire the "light bulb" that shows our solution can help than to detail it out.
• 30 June 2020: "Preferences" assume people each have their own laws. Like each person is a universe with different rules. "Decisions under circumstance" assume people all decide the same way but have different inner and outer temporary conditions. One universe with the same rules.
• 30 June 2020: Would love to figure out how to spell this out. Preference vs. decision under circumstance Preference invokes a static structure in the person. Like a riverbed that always channels water the same way. Decision under circumstance invokes a dynamic structure in the world.
• 30 June 2020: The motivation behind this is ... whether getting a notification is helpful or annoying depends completely on your purpose. Some projects I want to know every little thing. Others just high level updates. Others shouldn’t bother me at all.
• 30 June 2020: Example of included: I’m added to a project so I can know what that team is doing, but any notifications about it would just be noise to me.
• 30 June 2020: Yeah don’t expect these to make sense as single words. Keep me informed is somebody who should get a report, be kept up to date on progress. But not bothered with every little thing. Included is when they don’t need to be notified about anything at all, but they can come look.
• 30 June 2020: I’m fine with just talking. Don’t need a methodology.
• 30 June 2020: It wasn’t riskier than BC2->BC3. Similar cost. Similar worst-case scenario. And the two year bet wasn’t made all at once. A number of small bets led up to the bigger appetite.
• 30 June 2020: Re: implementation .... example: Should this person be notified of every little thing the minute it happens? Responsible in the core team: Yes VIP who wants to be kept informed: No Person not involved but included for transparency: No
• 30 June 2020: Or demoing.
• 30 June 2020: Talking about something interesting.
• 30 June 2020: Looking closer at what software people have always called “access” or “permissions.” Reframing it: Instead is what are they allowed to do, what do I want them to do? Intention and expectation, not just limitation. Sketched a selection and gear shift metaphor. pic.twitter.com/RtSJMxYCQc
• 30 June 2020: This “inverted pyramid” concept is scale-free — you can apply it to today’s work, to a whole cycle’s work, or to prioritizing which thing goes into this cycle vs. that cycle. ( https://basecamp.com/shapeup/3.4-chapter-12#solve-in-the-right-sequence ) pic.twitter.com/3LaYRVNMRp
• 29 June 2020: That decision was made by @jasonfried and @dhh . There was a wall. Every 6 weeks was a wall. And they had an overall appetite for how many cycles they were willing to throw at it. BC3 and BC2 also took longer than 6 weeks. BC4 will too. The art is betting one cycle at a time.
• 29 June 2020: Now that virtual conferences are more common, this should exist: Rent-by-the-hour livestream studios. - Dedicated, fast-upload internet pipe - Good microphone - Good light - Nice backdrop - Sound isolated Doesn’t make sense for all conference speakers to set this up at home.
• 29 June 2020: Tired of slides. Going to try a new approach. Only use slides for high-resolution show-and-tell. Screenshots. Illustrations. Photos. Graphs. No bullet points. No giant word that indicates “this is what I’m talking about for the next 30 seconds.”
• 29 June 2020: Shape Up talks about “appetites” instead of “estimates.” But the appetite alone isn’t the wall. The wall is the enforcement of the appetite. We call that the circuit breaker in the section on betting.
• 29 June 2020: The difference between an “estimate” and a “wall” is so important. With an estimate, you can be wrong and just keep going. (Spending more and more $$). With a wall, you have to stop when you hit it. This changes the way you think about everything.
• 29 June 2020: “Time wall” is a basic, generating concept implicit in Shape Up. There’s a huge difference between working 2 wks at a time with no hard wall, versus an absolute deadline of 6 wks. The real, hard deadline (“wall”) pushes back on all decisions preceding it, motivating trade-offs.
• 29 June 2020: Giving a talk on Shape Up tomorrow at @9punto5_ . I don’t give the exact same talk more than once, so trying a new angle. Two main pushes: - Project-time: Time to ship too long - Strategy-time: Time to think too scarce Show how 6 wk time wall w/ autonomous teams solves both.
• 29 June 2020: Product strategy note: Eliminating repetition across an ensemble is different from eliminating repetition for an individual over time. (Not better/worse; just different classes of problem solving.)
• 29 June 2020: Love how Stripe keeps integrating further into the front-end to eliminate work that is repetitive across the ensemble of customers. (This is an example of a scale transformation: https://synthetic.transistor.fm/episodes/scale-tradeoffs-in-communication-and-design ) https://twitter.com/patrickc/status/1277684467134369793
• 28 June 2020: Nice response to the podcast so far, especially considering how niche it is. Unlike Shape Up, it’s not really designed for consumption or aimed at any particular demand. (Screenshot of @TransistorFM . Been happy with their hosting service and no-nonsense UI.) pic.twitter.com/IwVSF4mRl7
• 28 June 2020: Reminds me of Barry Smith’s distinction between ‘fiat’ and ‘bona fide’ boundaries. Imputed structure vs. actual structure. http://ontology.buffalo.edu/smith/articles/fiat.pdf
• 27 June 2020: ⭐️ Episode 3 of Synthetic A Priori: Scale Tradeoffs and Transformations Degrees of freedom at small vs. large scales, with connections to writing, communication, product development Nugget: "The end of R&D mode is when the scale transformation happens" https://synthetic.transistor.fm/episodes/scale-tradeoffs-in-communication-and-design
• 27 June 2020: Interesting piece on the dynamics of Spotify from a successful niche artist’s perspective. Cool to see that Discover Weekly has such an impact. https://www.stevebenjamins.com/blog/music-in-the-age-of-algorithms-47syg
• 26 June 2020: That's a fundamental point.
• 26 June 2020: So many fresh ideas here. Make shopping more like a video game, with a far bigger social dimension. https://twitter.com/kanyewest/status/1276609661047898112
• 26 June 2020: “How did you apply Shape Up to such a gigantic project (did I hear it took 2 years)?” 6 weeks at a time! https://discourse.learnshapeup.com/t/hey-and-the-shape-up-method/398/4?u=rjs
• 26 June 2020: Detail from the fence beside my driveway. You only see these kinds of touches when people build their own places. They’re scale-bound. Architects/developers looking at drawings and $$ spreadsheets don’t do this. (The landlady lives next door, she designed both houses herself.) pic.twitter.com/QAmdRHkGE1
• 26 June 2020: Going to do one round of changes before the upcoming print edition. The rest will wait for potential 2.0 or supporting articles.
• 25 June 2020: Even shorter: the threat of leaving is not cost-free.
• 25 June 2020: That is, ask yourself: If we don't fulfill this person's request, what are their options? Is leaving a better option? Or is staying and making the trade-off a better option? All of that calculus should happen before you even consider building something for the request.
• 25 June 2020: Key point to interpret a feature request: There may be some loss to the requester by not doing anything about the request. But there's also loss to the requester if they leave you and use another alternative. It's a trade-off. The request alone doesn't justify cost of action.
• 25 June 2020: On the other hand, if there's any uncertainty about the interrelationships between parts or the nature of the problem, the precautionary principle applies: better to put the circuit breakers in place by using Shape Up practices to cap your downside.
• 25 June 2020: For example, this means... Shape Up is not worth the overhead if you already ship complete projects in < 3 weeks. Applies to some very early startups. Not necessary when work is known because it's repetitive or involves small # of 100% modular parts (no opacity).
• 25 June 2020: Progress rigorizing the operating window for Shape Up. Given a project, let time-to-ship be a variable with: 1. Fatness of tail from opacity of internal/external interdependencies 2. Mode from naive estimate (1 week vs 1 month vs...) Opaque deps & mode > 4 weeks → Shape Up.
• 25 June 2020: Re: ergodicity, summarized it as “to realize gains, you first need to survive.” Survival is def the key point of thinking non-ergodically and longitudinally. Good lens for simplifying a subject that can get enmeshed in technicalities and complications.
• 25 June 2020: Fantastic talk by @nntaleb on Bloomberg Quant just now. “The Russians think in ‘bounds’, a very robust way to think. Markov bound, Chernoff bound...” Goes well beyond finance and mathematics. Also core to Shape Up. @bmoesta often talks about“walls” in time and systems.
• 25 June 2020: Wishing we had limits on interstate travel right now. We’ve gone green in most counties of NM but open borders to TX and AZ put that into question.
• 25 June 2020: For that reason I try to have a portfolio of things I'm shaping — some things that are long running puzzles and some things that we could whip together shortly for the next cycle if we needed something to do. For the latter case, < 1 week is often enough time.
• 25 June 2020: Helps to distinguish: the pitch is the deliverable that presents the shaped work to the betting table. The actual shaping can take anywhere from one day to years, depending on how long it takes to have the needed a-ha or fill in the missing gaps in the concept.
• 25 June 2020: I learned UI design using no-code tools like Access and Filemaker in the 90s. Still think it's a great way to introduce people to the front-end/back-end, view/data split without getting bogged down in implementation detail. https://twitter.com/mijustin/status/1275952348544655360?s=20
• 25 June 2020: ryan@basecamp.com (early access to custom domains on Hey)
• 25 June 2020: Start by identifying the areas where the team is struggling, talk about those with the team to align motivation, and pick out which practices you think will help to start.
• 25 June 2020: Great to hear. Thanks.
• 24 June 2020: Definitely, provided they all read the book first and have questions ready. DM or email to coordinate.
• 24 June 2020: The fact that @_buildingbeauty exists means his work is alive. So exciting and cool.
• 24 June 2020: Two early takeaways from the podcast: 1. The “Site Repair” pattern is more fundamental than I realized. Obvious in principle, subtle in application (see Shape Up: Compare to Baseline https://basecamp.com/shapeup/3.5-chapter-13#compare-to-baseline ) 2. The idea of shaping outdoor space before building the volumes. https://twitter.com/rjs/status/1275872203863552000
• 24 June 2020: Hope to pull some clips out of this later. Susan Ingham’s emphasis on the Site Repair pattern was eye-opening.
• 24 June 2020: This is such a joy to hear: Two students of Christopher Alexander describe what it’s like to work alongside him, and describe the design and build process. And so awesome to hear his process is being taught now via @_buildingbeauty , his school in Italy. https://overcast.fm/+O_ODxUCqA
• 24 June 2020: More specifically, the definition of “performance” attributes is unique to the job. Eg our new product http://hey.com is missing many “basics” like support for signatures, copying quoted text, etc. But far outperforms on “control what I see” with the Screener.
• 24 June 2020: Kano is relative to the job. Need to put a reference frame around it. The fact that two people each use smartphones doesn’t mean they’re actually in the same market, buying for the same reasons, with the same requirements.
• 24 June 2020: Fines if caught ... is this sufficient? Wonder if this enforcable enough.
• 23 June 2020: Learned it from @bmoesta who learned all of this stuff and more from Taguchi directly. As you know, what gets passed down person-to-person is different from what gets passed down through books.
• 23 June 2020: No unfortunately. All the case studies in the books take a single block of one system, with one signal coming in and one response going out, and looks out how to tune the parameters of that.
• 23 June 2020: Will likely share more on this over time. It’s been a big focus for me lately.
• 23 June 2020: Background is from Taguchi methods. He called it “system design” in contrast to “parameter design.” Don’t have more to share on that because the bulk of his work is about parameter design.
• 23 June 2020: The fourth Shape Up Practitioner’s Meetup is tomorrow, Jun 24. Hosted by @davidarens . This one will be round-table style, with attendees sharing their own experiences with adopting and adapting to their teams. https://www.meetup.com/shapeup-practitioners/events/271421815/
• 23 June 2020: Super interesting podcast interview with @jonasdowney — who, along with @jasonfried , led the design of HEY — on their design process, what came first, and what was hard and different about designing an email service. https://overcast.fm/+JpthbZkGg
• 22 June 2020: @felipecb_ Cheers.
• 22 June 2020: I specifically drew your attention to a tweet where I said Android and Windows were innovative at the time they introduced those things. I think we’re talking past each other at this point.
• 22 June 2020: No. https://twitter.com/rjs/status/1275143593296986113?s=21 https://twitter.com/rjs/status/1275143593296986113
• 22 June 2020: Yes. Good marketing is like a promise. A promise alone isn’t enough. Need actions that fulfill it. Then you have a loop of reputation.
• 22 June 2020: My hobby podcast was approved by Apple today. Two episodes so far: 1. On connections between category theory, affordances, and jobs to be done 2. On unknowns as both risk factors and creative latitude Shape Up is in plain English — the podcast is not! https://synthetic.transistor.fm
• 22 June 2020: https://twitter.com/rjs/status/1272996096298455040?s=20 https://twitter.com/rjs/status/1272996096298455040
• 22 June 2020: “Positioned themselves as innovative” doesn’t mean anything. Nobody can “position” themselves with words alone. Everybody can see through it. Decisions and actions determine if the words actually resonate and mean anything. Otherwise it’s just wind blowing.
• 22 June 2020: Yes I’m saying Think Different worked because it described what they were doing. And prior actions and decisions put them into a position where the label resonated.
• 22 June 2020: Awesome.
• 22 June 2020: Oh interesting. A path-dependent “can’t get there from here” thing through the space of possible spaces of possibilities. Easy to imagine moving “up” into more complexity then back “down” but that’s an over-simplification. There isn’t one elevator. Lots of paths going out.
• 22 June 2020: Yes.
• 22 June 2020: First-order, deterministic, cause-effect thinking is undervalued.
• 22 June 2020: Maybe interpretable w/ Law of Requisite Variety. Like: Some jargon gives specific degrees of freedom. When that possibility space isn’t fitting for the task, need to raise complexity to get more degrees, choose new dimensions, then recompact.
• 22 June 2020: Yeah people will get much more out of it if they struggle first.
• 22 June 2020: - No, everybody doesn’t need to read it - All the core practices apply to tiny teams. Might need to alternate shaping with building if the same people do both. Bigger teams can parallelize. - Exact format of pitches doesn’t matter. Key points are shaping and derisking.
• 22 June 2020: Please consider this more closely. It’s not about better/worse or right/wrong. It’s about unique trajectories. https://twitter.com/rjs/status/1275167578873147392?s=21 https://twitter.com/rjs/status/1275167578873147392
• 22 June 2020: No, I’m not judging right/wrong at all here. I’m describing the dynamics and saying here’s a productive way to think about these decisions.
• 22 June 2020: (Credit @bmoesta for the electromagnetism analogy.)
• 22 June 2020: In plain English: a brand is the result of doing the same thing over and over. If you want to obtain the advantages of a good brand, or avoid the disadvantage of a bad reputation, look at the individual actions that get repeated.
• 22 June 2020: To all invoking “brand” to explain Apple’s strategy, choices, or advantages, here is Branding 101. Brands have causes. They are second-order effects of first-order actions. Like magnetism from a coil of electric current, if you stop the current, you lose the magnetism.
• 22 June 2020: Market shares don’t fall from the sky. They come from differentiation. Focus on causes not effects.
• 22 June 2020: My dream is to build some kind of design course that gives the lessons I learned through hacking a custom path. I wish it just existed and I could snap my fingers!
• 22 June 2020: Brand is not a magic halo. It’s an effect of past actions. If we care about brand, we should focus on what causes brand not what advantages brand confers. If we don’t understand what causes it we won’t understand what sustains it and it will dissipate.
• 22 June 2020: That’s the point. How do you become a brand with these advantages? By doing what I described in the first place: differentiating decisions based on a different POV about what matters. Brand is the second order of what we’re talking about. Understand first order to get there.
• 22 June 2020: Because we don’t give them a wireframe ... What’s left to the designer is all the design work: A million decisions about how to position and style and arrange things so they actually work and look good and make sense at actual size with all trade-offs addressed.
• 22 June 2020: “What’s expected” is a function of the specific demand you’re trying to meet. Android, Apple et al are not selling to the exact same customer in the same situation with the same fitness criteria. That means they can define “what’s expected” differently. See Kano.
• 22 June 2020: Yes.
• 22 June 2020: Agree. Always helps to separate the marketing from the underlying strategy when we want to critically understand these things.
• 22 June 2020: Each company is on its own trajectory, with its own differentiation at a given point in time. While Android innovated there, Apple innovated somewhere else. These are unique paths. We learn the most by looking at them longitudinally, not cross-sectionally.
• 22 June 2020: @SofiaPiresG Beyond those no-code starting points, to get some hands-on skill, avoid complex Javascript stuff like React. A basic Ruby on Rails course can show you all the moving parts in one small system, which you can later apply analogically to any stack.
• 22 June 2020: I wish I did. IMO most important is learn about basic wiring between front-end and back-end: views and data. I first learned using no-code database tools like Filemarker and Access. Graphic design/style doesn’t matter here. More about getting buttons and fields on the screen.
• 22 June 2020: Hoping to do some live streams with companies that want advice or feedback on how they’re applying it.
• 22 June 2020: 1. Years-long process articulating how the small founding team did design/dev & defined process as we grew. 2. Succeeded. Core teams did it well. @jasonfried suggested I write a book. 3. Prototyped w/ workshop to learn what matters to other companies. https://m.signalvnoise.com/how-i-wrote-shape-up/
• 22 June 2020: By far the best outcome of publishing Shape Up: I’ve started having really deep conversations with lots of product people because we have a better, shared language. It’s been almost a year since v1.0 came out now (!)
• 22 June 2020: Agree. The Product 101 point is about the sequencing and timing of the work.
• 22 June 2020: Exactly https://twitter.com/rjs/status/1275143593296986113?s=21 https://twitter.com/rjs/status/1275143593296986113
• 22 June 2020: Also different integration of skills inside the timebox for an R&D bet. Shaping and building get mixed into a slurry of improvisation as they try different things to learn what works. Versus for shaped pitches, shaping is pre-bet and build is post-bet.
• 22 June 2020: But there’s no way to get to a new product architecture without that R&D time. So if we think we have enough of an idea that’s worth spiking, we can say our appetite is X weeks to explore that. Still a capped bet. But different outcome than a shaped pitch.
• 22 June 2020: 100% standard betting table. We all only get 24 hours every day and have to make trade-offs on how to use it. The difference is we can bet time on a shaped pitch, and expect to ship. Or we can bet time on an R&D question, with no clear expectation of what comes out. Higher risk.
• 22 June 2020: Research is an input to shaping. To know what to make, we do work up front to understand the demand & constraints. Many UXers focus on validating concepts. That’s build -> learn. We do the opposite. First we learn the problem. Then when we’re confident enough we bet on building.
• 22 June 2020: Credit to @chriscbs for the term “slapdash meeting” to explain that ineffective but common approach to deciding what to do next. https://demandthinking.com/episodes/2019/10/23/episode-3-the-slapdash-meeting
• 22 June 2020: Bet-making is power + opinion. But shaping isn’t. Shaping means doing work: research + modeling + sketching + spiking. Takes time, skill, effort. Not a meeting. Package the shaped work as pitches. Then the betting table excercises power on carefully considered potential bets.
• 22 June 2020: Shaping and pitching is underrated in lots of companies because their decision-making process is slapdash: put everybody in a room and talk until something happens. Defining work requires doing work. It’s not just a conversation or an opinion.
• 22 June 2020: Yes doing actual work. Not herding people who do actual work.
• 22 June 2020: When leadership is too “macro” it means in effect nobody has clear direction. Only leadership can put up the containing walls and provide the grease so that projects have the right people at the right time to get the important things done.
• 22 June 2020: Opposite. Leadership needs to take more interest in placing specific bets on projects. Opportunity is for PM to do the deep work of framing and shaping potentia lbets.
• 22 June 2020: Common Q: “What’s your role as a PM when your org uses Shape Up?” Shape Up obsoletes standard PM. Outsources betting UP to leadership. Outsources execution/time management DOWN to cross-functional teams. But creates an opening: PMs with design/tech skill can become Shapers.
• 22 June 2020: (Or temporarily low on resources to ship differentiating ideas.) https://twitter.com/rjs/status/1275143593296986113?s=21 https://twitter.com/rjs/status/1275143593296986113
• 22 June 2020: Common question: “Did you follow the Shape Up process for building http://Hey.com ?” Answer: 100% See this thread on how we apply Shape Up to develop brand new products: https://twitter.com/rjs/status/1259338296171192321
• 22 June 2020: It can be interpreted either way. In my experience sometimes we ship low-hanging fruit because we don’t have a better idea. But other times, we ship low-hanging fruit because we have a HUGE idea that will take more time and we need to do something in the interim.
• 22 June 2020: 100%. Here’s a thread about how Shape Up applies to new product development like Hey: https://twitter.com/rjs/status/1259338296171192321?s=20 https://twitter.com/rjs/status/1259338296171192321
• 22 June 2020: Plenty of quips today about Apple introducing features seen long ago on Android or Windows Phone. This is Product Strategy 101. You prioritize things that differentiate, not things that make you the same. Catch-up features fill in later, when you’re low on differentiating ideas.
• 22 June 2020: Appreciate all the shoutouts on HEY. Core team credit should go to @jasonfried , @dhh and @jonasdowney (with countless contributions from all the teams at @basecamp ). https://twitter.com/joeri_vc/status/1275089883325960193
• 21 June 2020: Love how http://dithering.fm is both shorter than most podcasts (15 minute episodes, complete with ticking stopwatch sound effect) and also charges $5/mo for access. Perfect counterintuitive microstudy on value and pricing.
• 21 June 2020: ⭐️ Episode 2 of Synthetic A Priori: On two kinds of opacity (uncertainty) and a link with creativity https://synthetic.transistor.fm/episodes/opacity-and-creativity (Waiting for Apple to update their podcast directory. Use the 'Subscribe' URL until then.)
• 21 June 2020: Stanley Donwood on designing Radiohead's OK Computer album art: "We didn't use Undo. So instead of getting rid of a mistake, we would put something on top of the mistake." https://youtu.be/M5_Dcgewa1Q?t=159 pic.twitter.com/OPm3sSNm42
• 20 June 2020: Yes an affordance is an interaction between the structure of what's there on the one side and the perceiver's faculties and past experience on the other side.
• 20 June 2020: Figuring out what to do next, both in terms of defining the problem and shaping the key points of the solution.
• 20 June 2020: We’ll continue to aim at businesses our size and smaller (we’re ~50 people).
• 20 June 2020: In software, there are more links in the chain than when pouring from a teapot. There is functionality that is hiding in the code, and the interface needs to expose this functionality. So it’s helpful to distinguish what exposes the functionality from the functionality itself.
• 20 June 2020: I appreciate your POV @jujodi , but for me I find it more operationally useful to consider, from your example, “submitting”, as a backend function and then say “I need some affordance to trigger that”, which means either a button or something else.
• 20 June 2020: Shape Up sits within a specific context: helping people to transition from wireframes and pixel mockups to a higher level of abstraction. From that perspective, saying “it’s a button” is much better than “it’s a button with this shape, to the left of that, and in this color” etc.
• 20 June 2020: Very good clip.
• 20 June 2020: I also consider Ronald Langacker’s work very phenomenological despite belonging to the category of linguistics. Things like profile/base, landmark/trajector, scope, etc can be located analytically in speech expressions but he describes them more like direct objects of experience.
• 20 June 2020: Gian-Carlo Rota did some good phenomenological work on function as well. Used Husserl’s notion of fundeirung to distinguish afforded functionality from the basis that does the affording.
• 20 June 2020: For example Husserl’s epoché is abstruse but actually very applicable to design work. You “bracket” out what you know about the thing and look at it with fresh eyes, as it’s given to your faculties, and say ok what possibilities does this present.
• 20 June 2020: Yes this stuff is all totally from a phenomenological stance.
• 20 June 2020: *facilitates. Another example: if a button looks like a button, it affords pressing. The affordance is the recognizably pressable thing. IMO adding the notion of a signifier on top isn’t necessary and complicates it.
• 20 June 2020: Just re-read your tweet. I see what you mean. Because you could drag anywhere on the sheet, not just the handle. I’d still prefer to say that the sheet has some structure that shows it is draggable. And whatever facilities that recognition of draggability is the affordance.
• 20 June 2020: In that case the sheet isn’t the affordance. The handle is the affordance. Affordances afford actions. If you can’t act upon it, it’s not an affordance.
• 20 June 2020: Exactly.
• 20 June 2020: “A typical development ... starts with a drawing. We’ve assumed that if it’s a good drawing then the thing is gonna be ok. That’s simply a mistake. Life cannot be produced from a drawing. Life can only be produced from a process.” – Christopher Alexander https://vimeo.com/223830624
• 20 June 2020: That is when we think we need to eg. press something, we will notice pressable things and even perhaps try tapping unpressable things because they might be pressable.
• 20 June 2020: No it’s not a limitation, it’s a richness. It shows how the functionality of things is recognized by the structure of the things embedded in some context, not imposed.
• 20 June 2020: Thread on affordances vs. signifiers and recommended sources for thinking about these kinds of things: JJ Gibson and Ronald Langacker. https://twitter.com/rjs/status/1274205061703294976
• 20 June 2020: http://basecamp.com/shapeup
• 20 June 2020: To round this out, def recommend looking at Gibson’s work to go deeper on affordances. Then on the subject of signification, I’ve found Ronald Langacker’s Cognitive Grammar to be far more useful for real problems than anything in, say, semiotics. His introductory text is amazing.
• 20 June 2020: I like to use Kauffman’s screwdriver example to show how far the concept of affordance goes beyond signification. https://www.wbur.org/npr/135113346/there-are-more-uses-for-a-screwdriver-than-you-can-calculate He shows we can’t prestate all the functions a thing affords. (Signifying requires prestating, because sign & signified come together.)
• 20 June 2020: This subject gets a little tricky with user interfaces because everything is an image on a 2d surface. But I think you can still differentiate between structure (“this appears pressable”) vs explicit signs. “Submit” and “Cancel” are both affordances with different signifiers.
• 20 June 2020: The notion of an affordance is more general than a signifier. The reason is: what a thing affords comes from its structure. Eg the teapot handle affords lifting and pouring by its shape, not because of a label on it saying “handle.”
• 20 June 2020: Don Norman didn’t invent it, it’s from JJ Gibson. Have a look at the original source: The Ecological Approach to Visual Perception.
• 19 June 2020: Loved this bit of trivia from the Ergodicity Economics Lecture Notes ( https://ergodicityeconomics.com/lecture-notes/ ). Matches my intuition that “paths” are the main object of study in EE and the areas it overlaps (systems where you decide what to do by looking at cause-effect and change over time). pic.twitter.com/IONo0aAP0O
• 19 June 2020: The “JIRA vs Basecamp” thread captures two different ways of working. Tickets: “We know the work. Do these ten things.” 🤦⏳ Shaping: “Come up with a way to fill this gap.” 🧏🧠💡 https://twitter.com/therealzooce/status/1274078118278397952 pic.twitter.com/YGdxBgF7cT
• 19 June 2020: Not sure yet but we’d like to have a DRM-free ePub so that the Kindle isn’t the only option. Focused on print layout and publishing in the near term.
• 19 June 2020: It’s the backpacker’s principle: leave the site better than you found it.
• 19 June 2020: We don’t allocate time to pure refactorings or tech debt. Our programmers refactor on the way to new behavior, not just for the sake of refactoring.
• 19 June 2020: Yes and yes. There’s also a supply side part of problem definition. I may have a good sense of the problem, but not enough knowledge of interdependencies in the existing system to shape something.
• 19 June 2020: @jasonfried is last word on product and led the design and concept of Hey. I give input on product direction and shape projects, specifically for Basecamp right now.
• 18 June 2020: How you cluster the jobs and how you detail the jobs are two different things. One is about separating. The other is about filling in. Yes after you've clustered the jobs, then you fill in with the habits and anxieties for each cluster.
• 18 June 2020: First look at the supply side: How's this hurting us? What's the loss? Then if the loss matters, look at demand side: do we understand why they're asking for this? That will give you appetite then reqs for shaping.
• 18 June 2020: It's all about reaching for the tool when you need it. I don't do interviews unless I feel like I'm in the dark. Then I use them like a flashlight.
• 18 June 2020: Straight Shape Up. See this thread: https://twitter.com/zamith/status/1259225907488796672?s=20
• 18 June 2020: For Basecamp, yes.
• 18 June 2020: No formal JTBD went into Hey. @jasonfried and @dhh were clear on the struggles with email they wanted to solve for themselves. We reach for JTBD in situations when we don’t know what to do. But interesting how solving clear struggles looks like JTBD anyway to the outside!
• 18 June 2020: Fastest right now is to import the spreadsheet into a tool called JMP that does the clustering. I haven't checked in R but I have code to do it in Python. I can give you details over DM. Also have a work-in-progress web app that does all of this end-to-end in private alpha.
• 18 June 2020: Think of a job as trying to get from "here" to "there", from some context to an outcome. The pushes and pulls capture those pathways. Habits and anxieties are for doing the job better, not defining the job. Eg you can remove anxieties to improve conversion and adoption.
• 18 June 2020: Yes! https://twitter.com/kevinwhoffman/status/1273447153977999360
• 18 June 2020: Yes!
• 18 June 2020: It’s slightly better when I intend for someone other than me to read it.
• 18 June 2020: I love Notability but sometimes the iPad just feels too small. Interesting how the scale of a sketch doesn’t matter in theory but totally does in practice sometimes. pic.twitter.com/i64hUEFaI3
• 17 June 2020: Amazing, deep write-up on adopting Shape Up by @JohnStokvis . “So I made a radical decision. I would set the boundaries for the project, but all the decisions within those boundaries were up to the team.” Read it here: https://www.johnstokvis.com/writings/2020/5/7/implementing-shape-up pic.twitter.com/cGQ1pbhKdj
• 17 June 2020: This is going to be a must-read. https://twitter.com/bmoesta/status/1273212122906984448
• 17 June 2020: When it does what it needs to do scratch the itch, within the amount of time ($$) you’re willing to spend on it, and a bit earlier than you’re comfortable with.
• 16 June 2020: Yeah tried that on the first pass. Didn't work.
• 16 June 2020: This is why the notion of "appetite" is so important. It's an additional degree of freedom beyond "good idea / bad idea." https://twitter.com/rjs/status/1273027963328626692?s=20
• 16 June 2020: Wasn't obvious to me either at first that it was possible to frame your idea as a change in the categories! I don't think we're likely to go there because of appetite constraints on this particular subject, but interesting.
• 16 June 2020: If we introduce the notion of "question" to the extent that we could actually know it's a question, then it becomes a category we could segment behavior on.
• 16 June 2020: Yes. By my definition, type of content is a category :)
• 16 June 2020: "E.g. the signal „Task marked as done“ has probably a much higher priority than the 20 comments leading to that state." No. If a task is blocked on a question in a comment, the comment is more important than the completion. Context matters. You're oversimplifying.
• 16 June 2020: It's a bit too early to say what the next step is :) This is a deep subject with a lot of interactions. Thus the orthogonal array. And there's a lot of context I can't give due in a few tweets.
• 16 June 2020: Appreciate your point about notifications on the same thread. What you describe falls into the parameter of category (comment vs completion). I'm looking at batching across different tasks/threads as well.
• 16 June 2020: I'm referring to something else. Talking about batching notifications together. Eg 1 notification about 10 things instead of 10 notifications about 1 thing.
• 16 June 2020: *Molenaar
• 16 June 2020: Thanks.
• 16 June 2020: Layout in progress. Everyone's busy with HEY but it's in motion.
• 16 June 2020: Yes this touches all fields I think. I learned about the distinction in parallel to the dev of EE from @bmoesta who learned it from his mentor Genichi Taguchi. There's also Todd Rose and Peter Molinaar's work (eg the 'pathways' chapter in The End of Average.)
• 16 June 2020: Thanks. Can you give an example of what "a daily or weekly prompt" is?
• 16 June 2020: This is a bigger, general fallacy. Segmenting by cross-sectional similarity instead of longitudinal cause-effect. Only the latter informs decisions about action.
• 16 June 2020: Can you tell me about the last time you wanted a recurring to-do? What were you trying to do and what was it for?
• 16 June 2020: What a cool thread of thoughts. Thanks.
• 16 June 2020: @twitwitwitwoo Yeah those are exactly the kinds of questions that are coming up in this work. Thanks.
• 16 June 2020: Good to see. Will continue to work on this. I believe we can unpack the pre-shaping work more over time. There's a common timeline that parallels the first thought -> passive looking -> active looking -> deciding chain from demand-side job-to-be-done theory.
• 16 June 2020: Cross-sectioning destroys information about causality (because causal relationships run in the time direction not the space direction). For my work at least I'm learning to restrict cross-sectional data to the special case of measuring the scale of understood causal patterns.
• 16 June 2020: Love the idea of weaving guests into it. Thanks.
• 16 June 2020: Re: the overlap, from a product-maker's standpoint, the ensemble POV not only gives wrong answers, it's the wrong type of data. Need to look at individual threads of action in order to unpack decision-making enough to understand where the gaps are to provide better functionality.
• 16 June 2020: Been following Ole's work for a couple years now. There's interesting overlap between EE and work that I do isolating chains of cause and effect to understand what to build for customers. We collaborated on the first steps of the Microfoundations of Discounting paper.
• 16 June 2020: Some folks have asked about the Shape Up audiobook. Here’s an update. Think we’ll end up doing a podcast miniseries instead. https://twitter.com/rjs/status/1272995647214387201
• 16 June 2020: WIP is to think of this as an “ask” not a “task” and model flows around that.
• 16 June 2020: Recorded the whole thing and on playback realized it wasn’t making sense without the illustrations. The text refers to and weaves so much with the illustrations and screenshots that whole chapters didn’t make sense without them. We’re considering other approaches.
• 16 June 2020: Cool to see thoughtful followup questions on older threads like this. Really rewarding to have such an engaged audience here. Thanks for the questions. https://twitter.com/pamela_drouin/status/1272924502188490769
• 16 June 2020: It’s quantifying quality. It’s about a function to be performed and a metric of quality. That’s scale independent (the function could be at the big hire level or little hire level or subsystem level).
• 16 June 2020: For the sender of the notification, the metric and loss function is different. It’s not about time-to-process. It’s about time-to-get-informed. How long to wait before some reaction or response to the notification. The loss F(X) is what goes wrong when too long/short.
• 16 June 2020: For notifications, the loss function is different for sender and receiver. For the receiver, time-to-process is a good metric. Take that as X and look at loss as F(X). Eg when bulk is too little, too many clicks. But when too much, too long to parse.
• 16 June 2020: An orthogonal array is a way of spanning a space of parameters to empirically learn which parameter combinations create the best outcomes. Very different from hypothesis testing. There is no hypothesis. Doing this requires a metric for comparing outcomes: the “loss function.”
• 16 June 2020: Creating an orthogonal array per Taguchi for the first time. Trying to improve quality of notifications in BC4. Control factors include: frequency (time between), bulk (# of items at once), category (Ping, assignment, comment, etc). Learning (and productively struggling) a lot.
• 16 June 2020: Intent is what someone is trying to do. Eg in this case, they’re trying to present the work to someone as a question instead of an assignment. The mismatch between what they’re trying to do and how the existing system works presents an opportunity to shape something new.
• 16 June 2020: Eg. I learn people are creating to-dos with no assignee. They @ mention someone in the notes area. Why? Because, in their role, assigning is too abrupt; they want to ask the person first. Now that I understand their intent and desired outcome, I can consider design changes.
• 16 June 2020: Excellent talk.
• 16 June 2020: On the order of weeks and possibly sooner.
• 16 June 2020: Not much logic ... kind of a "because we could" thing that spiced up the page. I always regret stuff like that — elements that don't have a strong purpose behind them. They're cheap to add but expensive to keep because you can't take them away later without upsetting people.
• 16 June 2020: There's no automated response. You're on it.
• 16 June 2020: Yes.
• 16 June 2020: Recommended https://twitter.com/bmoesta/status/1272694567226281988?s=20
• 16 June 2020: You can join the waitlist right here: https://hey.com/soon/ Everyone on the waitlist will get an invite before long.
• 16 June 2020: Whatever happens next, the bar has been raised. HEY sets higher expectations for the control and privacy of your email and exceeds them. Awesome work by @jasonfried @dhh @jonasdowney and the entire Basecamp team. https://hey.com
• 16 June 2020: "Real life is not an experiment" Powerful point from @nntaleb that invites us to question the relationship between science and action. (From https://forecasters.org/blog/2020/06/14/on-single-point-forecasts-for-fat-tailed-variables/ ) pic.twitter.com/hp3lW4dqyr
• 15 June 2020: I might have overshot your question. More shortly, yes.
• 15 June 2020: Start by looking at the difference between engineering and physics. Physics tells you what's possible in theory. Engineering is about making things work in practice. "Computer science" can mean diff things but tends to be more about the theory and possibilities of computing.
• 15 June 2020: In the eg. about Twitter, I didn't know if other people would also see it. But the network connectivity gave the possibility for 10x 100x 1000x more to see. In that sense convexity is a kind of leverage where the amount of leverage you get is a nonlinear function.
• 15 June 2020: That's why we talk about being convex "to" something. Suppose I reserve 20% of my time for crazy ideas every week. When a crazy idea comes, I can explore it. It's possible none of my ideas will turn into good projects. But carving the time makes me convex to the possibility.
• 15 June 2020: Both are about getting more output from the same input. Difference is opacity and linearity. Leverage usually refers to situation where you get X more, and the X is known. Convexity refers to situations where X might explode upward, and you don't know by how much in advance.
• 15 June 2020: Found it. Thanks!
• 15 June 2020: Unfortunately they don’t let you Save to Files. Would open up more possibilities to share. /cc @OvercastFM
• 15 June 2020: Made the image above using Notability on iPad for super quick compositing. 1. Took screenshots on iPhone 2. Opened Notability on iPad 3. Imported photos (which are now on iPad via iCloud) 4. Drew annotations 5. Took a screenshot to upload to Twitter pic.twitter.com/3R4OUYI1gJ
• 15 June 2020: Love the UI and flow for sharing a clip from @OvercastFM . Great example of integrating something people used to do outside the app into the app, and then getting multiple wins out of it (more sharing, exposing Overcast to more people, etc). pic.twitter.com/zdVGo06FwB
• 15 June 2020: Yeah the way to think about it is in causal relationships ... what can you do with this knowledge vs what goes wrong when it’s lacking. Shaping is solution design so if you don’t know the medium of the solution things will blow up on you.
• 15 June 2020: Convexity in action: Answering a Shape Up reader’s question over email helps one person with some time spent to answer. Capped cost, capped upside. Answering the same question on Twitter may help lots of people or introduce new people to the book. Same cost, but convex upside.
• 15 June 2020: Great question on the relationship between coding knowledge and shaping. See responses in thread. https://twitter.com/floev22/status/1272623136744357888
• 15 June 2020: Those dependencies are in the code and are expressed in terms of code. So knowing the code (how the existing system is implemented) or improving your ability to communicate with people who know the code is a big advantage. Lets you make more targeted pitches with less risk.
• 15 June 2020: One of the biggest risks is you think you can do feature A, but it turns out that A depends on features B, C, D, E. If you don’t know about those dependencies, the scope of the project blows up on you. If you do, you can change the shape or hammer scope in advance.
• 15 June 2020: More specifically, more code literacy can help you to talk to a programmer before the pitch is ready and say “We’re thinking of doign this. If we pull this string, are there side effects I don’t understand? What else depends on this thing?” Etc.
• 15 June 2020: I’m learning to explain it like this ... Pitches are the deliverable, and there’s two steps before the pitch: - Shaping - Derisking Better tech knowledge will help you derisk.
• 15 June 2020: Thanks, let the team know.
• 15 June 2020: If you’re wondering how to start, I would recommend learning tools designed for very small teams first. React / heavy Javascript tools were designed by big companies with big-company problems. Rails, Laravel etc were designed to make small teams and individuals productive.
• 15 June 2020: Also these two worlds attract different people. The “carpenter” world is more amenable to generalists. I want to frame a house, make it stand, paint it, put the art and furniture in too. Vs. more algorithmic work is less integrative, more specialized, deeper in the engine room.
• 15 June 2020: Recruiters and boot camps often don’t distinguish the two. Especially with the rise in high-paying jobs in data science or deep learning/AI fields. Eg designing software to help a firm improve their business process is very different from optimizing YouTube recommendations.
• 15 June 2020: Also, there are two different worlds in programming that get easily mixed up: 1. The more mathematical world of algorithms, sorting, recognizing patterns, etc. 2. The “carpenter” world of making a functioning piece of useful software stand up and do something. My world is #2.
• 15 June 2020: I was in my early 20s. I don’t believe it matters how old you are when you start. More about whether your thinking style is compatible with it.
• 15 June 2020: From the POV of Hill Charts, percentage completion is misleading because of discovered tasks. https://basecamp.com/shapeup/3.4-chapter-12#the-tasks-that-arent-there
• 15 June 2020: Don Norman's book The Design of Everyday Things is the most accessible starting point, but doesn't go very deep. J.J. Gibson's book The Ecological Approach to Visual Perception is rewarding and gives a deeper intuition.
• 14 June 2020: Waiting for it to hit the apps. Might be 3-5 biz days. Until then, you can use the subscribe URL here to manually add to Podcasts: https://synthetic.transistor.fm/subscribe
• 14 June 2020: Key point to suss out whether some science piece is relevant to policy: Making predictions as an observer of a system is very different from acting inside a system. Actions follow from intentions and assume results. Totally different frame of thinking. https://twitter.com/yaneerbaryam/status/1272220950138847240?s=20
• 14 June 2020: Hitting the Fan: The Mathematics of Time and Survival
• 14 June 2020: Kant's Critique of Pure Reason
• 14 June 2020: A field. That's an interesting metaphor for it.
• 13 June 2020: Functional style as a response to opacity. https://michaelfeathers.silvrback.com/functional-code-is-honest-code
• 13 June 2020: Getting somewhere. Not tight enough for a write-up yet, but I talked it through in Part 2 here: https://synthetic.transistor.fm/episodes/category-theory-affordances-and-convexity-of-media
• 13 June 2020: Just had the idea this morning. QuickTime + guitar nearby + GarageBand + http://Transistor.fm + Adobe Illustrator + Twitter = instant podcast!
• 13 June 2020: ⭐️Here's an experiment. A new personal podcast where I talk about nerdy things: design, science, formal systems, architecture, etc. It's called Synthetic a Priori. Ep one talks about connections between category theory, affordances, and jobs to be done: https://synthetic.transistor.fm/episodes/category-theory-affordances-and-convexity-of-media
• 13 June 2020: We can tell ourselves whatever we want, but what works is empirical.
• 13 June 2020: "I’d even contend that said relief is the actual value delivered by the product." Then go try to design and market around 'relief' and see how you do.
• 13 June 2020: That idea of "delivering relief" is speculation. What they do for people is found empirically. Listen to this podcast for the details about the church and CrossFit case: https://thedisruptivevoice.libsyn.com/why-do-people-hire-religion
• 13 June 2020: Taste and preference are static, attribute-based, non-causal ways of looking at the world. They break down very quickly and don’t explain decisions.
• 13 June 2020: No no no no. All itch-scratching is like that, whether it’s social, emotional, or functional. Every itch, even emotional or “hedonic” as you say, arises in a certain context and can only be scratched by certain solutions. They are not globally substitutable.
• 13 June 2020: See this podcast for more on the example of church and CrossFit as competitors: https://thedisruptivevoice.libsyn.com/why-do-people-hire-religion
• 13 June 2020: Chewing on this. Category theory looks like tooling to describe a thing as what it does not what it is. Maps to demand-side segmentation. Surprising pairings eg. church vs. CrossFit compete when they do "the same thing" at some level of abstraction. https://twitter.com/rjs/status/1270843447474139136?s=20
• 12 June 2020: I might even do a higher fidelity mock than that if I feel I need to. But I won’t deliver that level of fidelity in the shaping doc. This step of spiking (making something more concrete in one small area) is for me to gain confidence in the macro idea.
• 12 June 2020: Sometimes higher fidelity than that. As much as I need to “see” what I’m picturing to find out if it works. Here’s a real example: https://twitter.com/rjs/status/1271253895088496640?s=21 https://twitter.com/rjs/status/1271253895088496640
• 12 June 2020: Doesn’t work on the trial document. pic.twitter.com/8lo2dDrZsk
• 12 June 2020: I got the trial of Flow and didn’t see any way to insert a photo for compositing.
• 12 June 2020: Yeah. That’s what I meant by “compositing” — being able to layer and crop and position different things.
• 12 June 2020: Twitter compressed some shading out of the video: pic.twitter.com/7jRYnL1CnP
• 12 June 2020: It’s about matching the speed of the tool to the speed of the task. If you’re got ideas in your head and you need to see them on paper, too many clicks/taps/steps is too slow. Vs if you are fine-tuning a finished producted, lots of clicks are just fine.
• 12 June 2020: It’s not about better or worse. It’s about the right tool for the right phase of work. A whiteboard is better for improvising than a CAD tool. A CAD tool is better for delivering a precision-honed drawing.
• 12 June 2020: Sticking with Notability. Turns out the image handling for simple compositing is quite nice. pic.twitter.com/VCJwv9bzNn
• 12 June 2020: Tried it. Concepts makes my brain hurt.
• 12 June 2020: Re: vector, yeah I also don’t care about perfection. It’s about manipulability for me. Will have a look.
• 12 June 2020: That’s the reason the illustration for the “find the elements” phase of Shape Up (chapter 4) looks like this. It’s performance and improvisition. Live experimentation. Not sitting down and drawing a wireframe. pic.twitter.com/n0T7Yizj3S
• 12 June 2020: Are the lines you drew with the Pencil manipulable after the fact? In a tool like Notability, all the hand-drawn elements are vector and you can move them with a lasso or easily erase them without messing up other elements on the page. Did you have to import those images first?
• 12 June 2020: Musicians distinquish between performance and composition tools. All creative people need the same. Whether it’s writing, drawing, designing... getting ideas out REAL TIME and experimenting is very different from producing finished deliverables.
• 12 June 2020: 2) Needs to be very fast and manipulable for this use case. To draw a music analogy, it’s more about performance than composition.
• 12 June 2020: Can anyone recommend an iPad app that’s good for both a) Hand-sketching ala Notability/Goodnotes and b) Compositing screenshots of existing UI? I do a lot of this when experimenting with a UI concept that affects existing screens.
• 11 June 2020: The sketch above is extremely schematic. I’m not confident enough to bet on it. Need to go a step more concrete and mock the part labeled S2•E8 to see if it works in practice. If those tw don’t go together, back to the drawing board. If they do, I’ll be confident to move on.
• 11 June 2020: A couple of them between cycles (every 6 weeks) is good. I’m always glad when I do more.
• 11 June 2020: In order to delegate and reliably ship within the time you’re willing to spend, the ‘how’ needs to be outlined. At the right level of abstraction. Not down to the fine details. See https://basecamp.com/shapeup/1.1-chapter-02
• 11 June 2020: Opinionated statement by a design + build firm in Oklahoma ( https://www.buildingculture.com/overview ). pic.twitter.com/kCSh9BPKGo
• 11 June 2020: It's not a meeting.
• 11 June 2020: It's most effective between peers.
• 11 June 2020: That is, "chance" might not be the high order bit. It's more about creating occasions to talk with no objective.
• 11 June 2020: Scheduled 1:1s with no agenda, for no specific project, fill some of this gap. Yesterday I had a 1:1 with our data specialist. Just to catch up. Led to rethinking the design of a major feature for BC4. https://twitter.com/paulg/status/1270622556098355201?s=20
• 11 June 2020: Print layout is coming along.
• 11 June 2020: I think a podcast miniseries, that adapts the content so no visuals are necessary, would be a good solution.
• 11 June 2020: We ran into trouble because the text depends so much on illustrations and visual examples in most chapters. The audio version was hard to follow. We’re considering some other ideas.
• 11 June 2020: Two things to avoid falling into a research/discovery hole: 1. Work at the right level of roughness, so you don’t spent time on pretty diagrams that you throw away 2. Sequence the most important unknowns first so you can blow up as early as possible if necessary https://twitter.com/rjs/status/1270869388363612160
• 11 June 2020: Exactly. It’s a scale trade-off.
• 11 June 2020: If I try to spell them out more concretely and there are problems, I might let go of the whole idea or look for a different approach.
• 11 June 2020: If I can solve those two (S1, S2•E8), I’ll be able to tell a story about how the pieces work together to do the new thing. Sort of like running an integration test and getting green.
• 11 June 2020: Ultimately they’re dual, but given a reference frame the distinction is meaningful. Eg framing an unknown to be solved or an unresolved detail within a whole.
• 11 June 2020: A lot of this early shaping work is about capturing dependencies and figuring out what parts of the solution are unknowns. This quick notation gives me context for tomorrow’s work: Sketch S1 to see how well it embeds in E3. Explore some options for S2 • E8.
• 11 June 2020: Notation techniques for the super early phase of shaping a feature. Pre-fat marker, pre-breadboard. Three systems (pieces of functionality) to introduce (S1..S3) Existing relevant systems (E1..E8) How some fit together, what to solve next w/ a sketch. pic.twitter.com/MiNqXNF1z1
• 10 June 2020: Worlds (to Roam)
• 10 June 2020: Team of three: “I dunno, we’ll figure it out.” Team of three delegating to another team of three: “Ok here’s the plan...”
• 10 June 2020: Much of the transition from a small team to a team of teams is about making what used to be implicit explicit. The biggest cost of making things explicit isn’t the extra time to do it — it’s the loss of optionality. Spelling things out makes them harder to change or back out of.
• 10 June 2020: So much good stuff unpacks from the screwdriver problem. Eg what things do is different than what they are. And that descriptions of what a thing is or does both depend on reference frames. That's before we even get to prestatability.
• 10 June 2020: The bit about the rock and the hammer gave me whiffs of Kauffman's screwdriver problem: https://www.wbur.org/npr/135113346/there-are-more-uses-for-a-screwdriver-than-you-can-calculate
• 10 June 2020: "Decontentualized" — that's a new one. On category theory as a way to work with functional contexts rather than contents. https://www.youtube.com/watch?v=jBkO1eerU8A
• 8 June 2020: The output/deliverable of shaping is a set of closed unknowns. Yeah the work of shaping is R&Dish because of the infinite regress — until it’s shaped you don’t have closed unknowns.
• 7 June 2020: That's what things like circuit breakers are for. I may think that everything I've shaped is a closed unknown. But I'll still cap the investment at 6 weeks (or whatever) so that if something unexpected bites, it doesn't drag us down indefinitely.
• 7 June 2020: Concerns about how/whether that aggregates audience on the social media platform rather than on the property you own? I could own all my blog posts, but if the channel were to go away, how would I reach those people again? Maybe your email list model is the third pillar.
• 7 June 2020: Right. Reduce to: knowledge of cross-project patterns. Difference is whether you need to acquire that knowledge (= added time/cost/effort) or already have it.
• 7 June 2020: Sometimes, as you create the new thing, you already have the knowledge of the cross-project patterns and cost isn't an obstacle. Eg @dhh creating Rails for Basecamp v1. That's a case of getting it all at once. But I believe it depends on all those factors coming together.
• 7 June 2020: Interestingly it seems you can't will modularization into existence. You get forced into interdependence when modular parts won't give the performance you need. Then to modularize, you need new knowledge of cross-project patterns or new technology to lower cost or both.
• 7 June 2020: This difference between open unknowns and closed unknowns is what really defines the edge between "R&D mode" and "Production mode" when we work on a new product.
• 7 June 2020: Shaping, then, is defining a bunch of closed unknowns. Or for fun we could maybe say a closure of unknowns, in the sense that you can operate on all the unknowns without new unknowns spiraling out.
• 7 June 2020: Good mapping.
• 7 June 2020: And .. importantly .. this is always patchy. We can use stock parts for 80% of the app and then build a custom thing for that special 20%.
• 7 June 2020: I would frame that under the schema of modularity vs interdependence, as Clay Christensen worked it out. With modularity you get low cost variety, but with a performance ceiling. For higher performance in some area, you make the trade-off and design custom-fitted parts.
• 7 June 2020: A distinction that applies to many Shape Up practices: Open unknowns vs. closed unknowns. An open unknown has no edges. You can't see how it ripples out in complexity or cost. A closed unknown has edges. Eg. we don't what color to make the button, but the question stops there.
• 7 June 2020: I like how your pushback raises lots of questions about when something starts to be a platform and where the edge of platformness is and what that means. Reminds me of a related question that came up today about objects vs environments: https://twitter.com/rjs/status/1269713585426403328?s=20
• 7 June 2020: The latitude between "it can do anything" and "it does one thing" is vast with massive cost and quality implications.
• 7 June 2020: Ah in this case I actually shuffled them around in an early attempt to group them into separate scopes of work. Then realized that wasn't working. Then reached for the interdependence diagram to solve.
• 7 June 2020: Example. Say I write "S1 — Log in" What the heck does "Log in" actually mean? Is it about authentication or authorization? Is it about plugging in a library or building a bunch of stuff by hand? As I learn I can rename it without losing the reference (S1) to this chunk of work.
• 7 June 2020: The idea behind a reference number like "S1" is it gives a way to talk about a piece of the system before I know what it actually does and what to call it. Naming requires knowing pretty well what a thing does. I prefer to name things late.
• 7 June 2020: Hm not sure. Depends on the level of abstraction. In general, I think the use sequences inform the requirements. Then the requirements inform the solution shape. Then the solution shape has interdependencies that inform the build sequence.
• 7 June 2020: I'm brain dumping pieces of work and giving each one a reference number as I think of it. No special order or sequence at first. S stands for system, but it's quite arbitrary.
• 7 June 2020: Second-order of that is expanding the size of green zones, erasing borders between green zones. But this depends on attitudes toward local borders. Not very popular in US and unclear (to me) what implementation would mean.
• 7 June 2020: The idealization of a Green Zone is a scale transition: from filters at individual scale (masks for particle movement) to filters at county scale (borders for people movement). If truly green, you get a scale trade-off: borders on --> masks off. https://twitter.com/yaneerbaryam/status/1269623245357174788?s=20
• 7 June 2020: It's easy to conflate these things in software. You don't need "log in" to see the view of one user's data. You need the user model and the code that filters the data by user. "Log in" is orthogonal for build but dependent for use.
• 7 June 2020: Use sequence and build sequence are extremely different things. Eg a house: Order of use: driveway -> front door -> hallway -> kitchen. Order of build: foundation -> framing -> walls -> etc.
• 7 June 2020: Important thing about the arrows: Arrows do not mean dependency in terms of use sequence. (Eg user has to log in --> they see their projects). They mean dependency in terms of build sequence. Need concept of account to wall off projects that belong to that account.
• 7 June 2020: (Note this is for a side project, not BC4. We aren't doing new project limits there.)
• 7 June 2020: Progress on a method to do what Shape Up calls "scope mapping" — factoring tasks into scopes. 1. Dumped all the tasks I knew, not knowing the sequence. 2. Arranged in a circle and drew interrelationship arrows (thanks @bmoesta ). 3. Nodes with most outgoing arrows are scopes. pic.twitter.com/kiRRkXYi8q
• 7 June 2020: I suspect there's a fundamental difference in kind between designing and object and an environment, and how you would define fitness for one vs the other. But I haven't thought about it enough.
• 7 June 2020: For Alexander, esp in later works, the core of the project (eg Eishin in "Battle") is a pattern language. The language isn't a language of misfits, it's a language of things that should be there. It's stated positive not negative. So I think they're commensurate in the end.
• 7 June 2020: 3) For both, you can see that misfit vs. primary function drive the design in different phases of the process. Per Taguchi, there's no reason to build a new solution if there's no misfit. The anomaly sparks the project. But the shape of the solution is defined via primary fn.
• 7 June 2020: I've chewed on that a little. Some observations: 1) There's a scale difference. What is the "function" of a neighborhood or house? It's more a lattice of functions. A tool/service has a narrower context. 2) Alexander doesn't lean on misfit very much in his later works. ...
• 7 June 2020: First collect the longitudinal data (dynamics) then cluster/aggregate up from that, rather than starting with cross-sectional data.
• 6 June 2020: Fantastic chart at the right level of scale: https://twitter.com/yaneerbaryam/status/1269248124125622272
• 6 June 2020: @winfred__ @benjkowalski A story like that can hit you over the head “ah I heard about that but never understood.” Or it can prompt ideas: we could explain more, or flip the default to show instead of hide from client.. Or flip back to distribution to size the story, now w/ variables from the story.
• 6 June 2020: There isn’t necessarily a conclusion yet. Conclusions require more work. But look at the questions that come up now. It’s a very different conversation with different possible next steps versus a single % number.
• 6 June 2020: I made up that example to show the difference between the two types of data.
• 6 June 2020: Distribution: 20% of customers use the client feature. Dynamics: Customer #1371 added User #125 as a client. After toggling every record “show to client” over and over, said “I don’t need this extra step.” Next project, she added her client as a normal user to skip the hassle.
• 6 June 2020: IMO rather than trying to make people rigorous, best we can do is 1. Attract those who are like-minded (it’s a fun party no matter how small) and 2. Apply any understanding we gain to problems that benefit the max no. of people. Then whatever results is positive.
• 6 June 2020: I don’t think saying the words == understanding it. Requires more rigor. Rigor isn’t popular.
• 6 June 2020: People say that but don’t practice it. Listen to nearly any podcast with an “expert” and you’ll hear correlations left and right as if they grant understanding.
• 6 June 2020: Btw knowing what not to do—from distributions—is helpful. A distribution can tell us 10% of customers use a feature, so it limits upside from improvements. Or it tells us risk of projects blowing up is non-zero, so we put circuit breakers on them. Beyond that, need dynamics.
• 6 June 2020: ... and aggregating longitudinally, not cross-sectionally. See @ole_b_peters ’ work.
• 6 June 2020: The fact that 80% of people who did X also did Y tells us nothing about cause and effect. It tells us nothing about how the system works. It doesn’t tell us why there is a relationship. This mistake is incredibly pervasive, including among most Phds and supposed experts.
• 6 June 2020: Any attempt to infer cause and effect from distributions is inherently flawed and will never work. You can’t get there from here. We can only make claims about cause and effect by observing cause and effect: individual chains of action.
• 6 June 2020: Distributions show you what not to do. Dynamics show you what to do. Most people looking at data in product companies only look at distributions. You can only get cause and effect—data that tells you what to do—from observing dynamics (movement of individuals).
• 6 June 2020: Glad to hear it resonates. It’s a minority view that hopefully starts to grow in our circles now. For some good real-world examples of that thinking, check Todd Rose’s book The End of Average, especially the section on “pathways.” It’s short and pithy. https://www.amazon.com/End-Average-Succeed-Values-Sameness/dp/0062358367
• 6 June 2020: Patchiness in practice: Q: “There’s a balance here that seems almost impossible to strike. . . . Shaped work can be either predictable or flexible, but not both.” A: It is both. https://discourse.learnshapeup.com/t/variable-scope-overwhelm/371/6?u=rjs
• 6 June 2020: A third one is just as important, but harder to talk about: 3. Dynamics. Look at how things move individually before thinking about how they aggregate as a snapshot. Understand one user’s footsteps from A-Z before thinking about what 20% of users do. Aggregate up, not down.
• 6 June 2020: Once you see these concepts, they apply everywhere. Planning a call? Think of scale. Don’t make a fine-grained agenda. Identify major unknowns to address and let the details emerge. Delegating work? Think in patches. Call out what is worrisome or isn’t or matters more or less.
• 6 June 2020: Two complex systems concepts (via @yaneerbaryam ) for product dev: 1. Scale. Be intentional about level of detail—coarse vs. fine—at all moments. Eg breadboard vs wireframe. 2. Patchiness. Not all or nothing. Some things matter, others don’t. Some things fixed, others variable.
• 6 June 2020: Talked for an hour on #subvisuallivetalks with @zamith . Topics included when Shape Up works and when it doesn’t, and how to view trust as an effect not a cause when it comes to product development processes. https://youtu.be/MTPhuf2EESA
• 5 June 2020: Wow. This WIP from @nntaleb @yaneerbaryam & @DrCirillo nails the problem with science journalism dead center. https://twitter.com/nntaleb/status/1268971068808671235 pic.twitter.com/MtzkJqlLBp
• 5 June 2020: Yeah will share the YouTube link after they archive it there from Twitch.
• 5 June 2020: This is what open peer review can look like. Step by step going through the data in a paper to interpret what it means or doesn't mean. https://twitter.com/JoeGuinnesss/status/1268651194420953088?s=20
• 4 June 2020: Nope. At small scales that self-organizes.
• 4 June 2020: Consistency isn’t a problem with a small team.
• 4 June 2020: About to go live now. https://twitter.com/subvisual/status/1268584579566313472?s=20
• 1 June 2020: On small teams, by @mfeathers . "The failure mode for larger teams is silent accumulation of technical debt due to lack of consensus and coordination." https://lobste.rs/s/yzd8hq/you_can_t_tie_your_shoes_while_running#c_xgvlpp pic.twitter.com/PKuiKMGT6q
• 1 June 2020: Great talk on how @FundApps adopted Shape Up by their Head of Product, Jonny Bradshaw. Here he spells out what pushed them to make the change. Recording of the talk: https://youtu.be/wfxwb11y7No?t=340 (From the latest Shape Up Practitioners Meetup w/ @davidarens ) pic.twitter.com/jBZ6Ij2RGL
• 30 May 2020: The book Competing Against Luck by Clayton Christensen is a good start. I learned the interview method from @bmoesta , who is featured in the book.
• 30 May 2020: Experiments require a reference frame. You can test 40 shades of blue if you want — no problem. Testing blue is different from testing the actual functionality of the sequence. That’s a parameter vs a system.
• 30 May 2020: There is a place for experiments to weigh the 8% vs 8.5%. That’s called “parameter design” in the quality world (eg. Taguchi). But designing the overall system is different from sweeping the parameters of the system. Need a causal view of A to B to C to design the bones.
• 30 May 2020: This is especially true for anything related to “conversion.” Knowing 8% make it through, and randomly trying things to see if you can get 8.5%, is not design. Design is understanding the links in the chain A to B to C, the causality of one to the next, and what has to happen.
• 30 May 2020: Good design requires thinking longitudinally. It’s not about sets and averages and 30% of these people vs 20% of those people. It’s about individual chains of action. When and how do you go from A to B to C to D to accomplish something. That’s how you solve problems.
• 29 May 2020: Alexander on boundaries: A boundary is “not a surface which divides inside from outside, but a coherent entity in its own right.” Counterintuitively: “the boundary zone . . . must also form a kind of meeting ground, where neighborhoods come together.” https://twitter.com/wrathofgnon/status/1036899480581230593?s=21
• 28 May 2020: In the end we always learn by shipping and it’s always a risk. But we should take responsibility to improve our odds up front.
• 28 May 2020: It’s a crutch people lean on when they don’t understand the problem and circumstance. The fact that the crutch is cheaper in digital doesn’t make it free, and lots of 2nd 3rd order problems.
• 28 May 2020: Loss is the negative impact when the function doesn’t hit target. Eg, I could lower cost by leaving an “edit” feature out of a chat app. That’s fine when people don’t mistype or use w friends. When they mistype with clients/superiors, they create an embarrassment they can’t fix.
• 28 May 2020: Cost is hours to build on 1st order. Cost of operation on 2nd order (eg if one design creates 10x more records this may raise storage or hosting costs over time). Cost of optionality on higher order — painting yourself in a corner wrt future changes.
• 28 May 2020: Need to write a primer on this. This is what’s called “quality” in more mature industries. Eg Toyota doesn’t ship different brake systems to customers to decide on the design.
• 28 May 2020: The interviews aren’t about whether a modal or page is better. The interviews are about what people are trying to do. When we understand that, we can judge which fits better. It’s our job to understand the function, cost, and loss of each alternative.
• 28 May 2020: Cause and effect is a different world than statistics. It’s less about “30% said x” and more about “when this happens (or doesn’t happen), that happens.” The struggles people want to fix and the outcomes they seek are causal.
• 28 May 2020: When you understand the cause and effect of the situation you are designing for. Unlike statistics, it’s binary. It clicks.
• 28 May 2020: Building working software is expensive. We don't do that unless we think we know what we're doing first. If we don't know what we're doing, we use cheaper methods like interviews to improve our understanding of what matters.
• 28 May 2020: Simple. Talking to customers and internal prototyping is cheaper than building and shipping working software. If you have to build + ship 2 things to learn what's better, that's 2x the effort on 1st order. On 2nd order it means extra coordination cost, waiting for results, etc.
• 28 May 2020: These fireplots are very informative when the scale is dialed down from state-by-state to county-by-county. https://twitter.com/yaneerbaryam/status/1265826205867089932?s=20
• 27 May 2020: Shipping to test is extremely costly and wasteful. Much better to do the up-front work to understand the problem better before shipping.
• 27 May 2020: This may be a better option than Zoom: https://hopin.to/ I was just informed that the INDUSTRY conference is using it for a remote version in September. They are very sharp guys who run a well-designed conf, so worth taking a look.
• 26 May 2020: Agree there’s an opportunity for design firms to define a deliverable/project this way.
• 26 May 2020: At the end of each cycle, when the team ships, someone from the team writes an internal announcement, which is greeted with cheers and applause.
• 26 May 2020: Rule of thumb for the integrity of ideas: Trust more when the purveyor heaps praise on their mentors and teachers. In this session with @DrCirillo , @nntaleb refers to “the great” Mandelbrot and how he learned from him to see fat tails across domains. https://www.youtube.com/watch?v=ggrW6qi0qZQ
• 26 May 2020: A side effect of narrowly targeting a job-to-be-done: People won’t value it until they’re actually in the job. Then the light bulb goes on. Important for judging reviews and feedback. https://twitter.com/gwynap/status/1265180090494828544
• 26 May 2020: The concept of a "job" as "what is it supposed to do?" applies on both demand and supply sides. But the way they are defined, the tooling around them, and the situations where you apply one vs the other are so different that it's good to carefully separate them with diff terms.
• 26 May 2020: Depends if you care about separating the peas from the potatoes. A demand-side job has functional, social, emotional aspects. Putting those words together could conflate things. I prefer to use "job" only on the demand side, like this: "People have jobs, systems have functions."
• 26 May 2020: Supply side vs demand side.
• 25 May 2020: The function of a "projects on a timeline" view isn't clear. What's the purpose? Or per Taguchi, primary function? Reframed as: show me what's supposed to be done and when so I know what needs my attention. Suddenly the design got a lot more focused.
• 25 May 2020: Example: I'm prototyping a "durations" feature for BC4 to see projects on a timeline. Many ongoing projects don't fit the mold. Lots of design Qs w/o clear answers. Reframed as "projects with a deadline" view. Now answers to the questions come easily. https://twitter.com/rjs/status/1265059881356128256?s=20
• 25 May 2020: Context isn't enough. Need to go a further next step to understand the intended function within that context.
• 25 May 2020: Ever been in a meeting where nobody could agree which version is better and why? That happens when there's no shared thermometer. In that case either (a) flip to problem space to define the thermometer or (b) work on something else where you understand the purpose better.
• 25 May 2020: The hardest part of designing is knowing when you're getting hotter or colder. That corresponds to the notion of a "quality metric" — but that can sound like a dry number. It's an understanding of what this thing is supposed to do, when it's doing it, and when it's not.
• 25 May 2020: A rare opportunity for a designer and a programmer to join the team at Basecamp coming soon. https://twitter.com/dhh/status/1265055364803788800?s=20
• 25 May 2020: The next Shape Up Practitioners Remote Meetup hosted by @davidarens is happening Wednesday May 27. Head of Product at @FundApps will talk about how their team has adopted Shape Up. Details, time, and how to join here: https://discourse.learnshapeup.com/t/shape-up-practitioners-remote-meetup/225/18
• 25 May 2020: Suggests there may be ways to experiment with round-robining or parallelizing which <5 people interact at a given time. Lecture sections are of course ok with bigger audience.
• 25 May 2020: There’s so much room for innovation on remote format. The space of possibilities has barely been touched. Important to untangle functional, social, emotional dimensions of the purchaser’s outcome criteria. Interaction over video chat effectively breaks down at > 5 people.
• 25 May 2020: Depends on the outcome sought by the buyer. If it’s about the content, 100% is fair. If it’s about meeting idols, more like 30%. Might get a higher price by carefuly designing interactive breakout video rooms so there is still idol contact + interaction among attendees.
• 24 May 2020: "The focus must now shift to what students can actually do with what they know. . . . higher education must embrace skills or competencies as the real measure of learning." Very in-tune piece by Paul LeBlanc @snhuprez : https://www.forbes.com/sites/paulleblanc/2020/05/24/can-higher-education-get-america-back-to-work/#4bf394867a97
• 23 May 2020: Yeah. Depends a lot on who you’re asking to participate and what their availabliity and interest is.
• 23 May 2020: I was recently invited to pre-record a talk and passed. I felt pre-recording asked more of me than just showing up and doing it. (a) Puts more tech onus on me, and (b) Takes away the “one shot” spontaneity and it’s hard to resist multiple takes/edits. May apply to other speakers.
• 23 May 2020: Zoom has a “breakout room” function that splits attendees into small groups for a short period of time to discuss. Could be this works better at small scale — eg only allow 50 people to event, break into 10 groups of 5 for discussion / to agree together on Qs to ask speaker.
• 21 May 2020: Localism https://twitter.com/yaneerbaryam/status/1263602599774892038
• 21 May 2020: Here’s an article with more detail on this type of questioning: https://m.signalvnoise.com/keep-digging/
• 20 May 2020: Neither. It's about level of abstraction. Applies equally well to visual decisions and implementation decisions. It's not about less or more, or separate or not. It's about what's the right amount of detail to define at this stage in the process.
• 20 May 2020: I need to understand what happened and why it mattered before I can go ahead and start to decide what to do about it.
• 20 May 2020: There's a huge difference between a story describing what someone wants vs a story about what happened in the past. Most "stories" in software dev are the former. Important difference: the latter contains no solution. That's further work.
• 20 May 2020: Next time somebody comes to you with a feature request, try this: "Can you tell me a story about a time that you wanted to do that and what you had to do instead?" The first part of the question gives you proper context. The second lets you evaluate the loss.
• 20 May 2020: Some non-programmers might not know what a "bike shed" is — the term comes from the unix community. Here's a reference: https://en.wikipedia.org/wiki/Law_of_triviality
• 20 May 2020: Why does this matter? Because the second you show this to somebody for feedback, they'll latch on to the specific words. You'll get sucked into a bike shed. The abstraction gives space to talk about what it's supposed to do and why it's there instead of the specific form.
• 20 May 2020: It's important to shape at the right level of abstraction. But that doesn't mean you can't dip into concrete details along the way, to figure out what to do. Example: The first sketch of S10 below has hard copy. The second abstracts to "what it does" & makes the copy soft. pic.twitter.com/X5gD6oSycB
• 20 May 2020: Answer in this thread: https://twitter.com/rjs/status/1259338296171192321?s=20
• 18 May 2020: This buyer's guide from Pitchfork brands the product shots w/ purple shading. It stops the page from looking like a million other buyer's guides on the web. Effective styling is like a voice that constantly reminds you who's speaking and where you are. https://pitchfork.com/features/article/9871-how-to-buy-the-best-turntable-and-stereo-system-for-your-record-collection/ pic.twitter.com/hEzlzglAQ8
• 17 May 2020: ^ This was a challenge. I don’t think I succeeded, but it got me thinking about two key contrasts: 1. Ensemble vs individual properties 2. Possibilities in space vs possibilities in sequence #1 is addressed by others, eg. EVT. #2 is more specific to EE: dynamics and repetition.
• 17 May 2020: Ergodicity is about systems of moving individuals. In “non-ergodic” systems the survival of the individuals is not reflected in the statistics of the group. For example a group of gamblers looks successful if one is a huge winner. But from an individual perspective, most lose.
• 17 May 2020: It is not the case that the designers are “front end developers in the cycle.” They make decisions about look, feel, interaction and copy throughout the cycle.
• 17 May 2020: Our designers do all three: concepting, visual design (down to the pixel), and implementing the front end views. For native elements on iOS/Android, they define the interactions and visual design in close collaboration with the programmers.
• 16 May 2020: Theory means you have an explanation of what's going on. Data alone only tells you about the past. Theory helps you make decisions about the future. See Competing Against Luck: https://www.amazon.com/Competing-Against-Luck-Innovation-Customer/dp/0062435612
• 16 May 2020: I believe it's the same if you abstract "design" to mean defining the behavior change and the affordances perceived by the user. APIs have interfaces too, and there is a meaningful difference between the design of the interface and the implementation.
• 16 May 2020: "It depends on maturity" It fosters maturity by creating conditions that make the designers and betters bump into reality sooner.
• 16 May 2020: That's what some successful Shape Up adopters have done in bigger orgs. Pair design and dev together in the shaping phase, before a bet is made to implement the project. This reduces massive amounts of risk and increases collaboration.
• 16 May 2020: @balajis @normonics "US government" is scale mismatched to the problem, therefore it's always been about the decentralized response. One entity can't manage the boundaries of red/green zones at the fine grain of patchwork necessary.
• 16 May 2020: Agree that's probably irreducible in some cases. One has to combine lots of skills to find simple solutions. But I think the context is a big factor too. Devs are often given too tight constraints or no constraints. Shaping can unlock creativity by setting clearer boundaries.
• 16 May 2020: Re: "culture and practice" agree and would love to unpack that. This is one specific lead. Any others? https://twitter.com/rjs/status/1261467207470469120?s=20
• 16 May 2020: https://basecamp.com/shapeup
• 16 May 2020: Yes, at Basecamp we have the awesome advantage of designers who code. But it's not a two-level thing: from throwing hi-fi mockups over a wall → coding designers. There's a level between: throw the right 20% of the design over the wall to specify macro behavior. Huge gains.
• 16 May 2020: Too many designer → programmer relationships are based on "implement exactly what I gave you." Tons of waste when the input is overspecified, with too much detail at the wrong time. And bad morale for the programmers too.
• 16 May 2020: Talking to more teams, I'm learning "designers who code" is fantastic but not the real secret sauce. Deeper issue is signal/noise of dev effort. When design specifies pixels, devs fuss with pixels. When design specifies affordances, devs ship behavior. https://twitter.com/MartinPeverelli/status/1261463328825569281?s=20
• 16 May 2020: Most companies are making big bets. Pixel perfect design, and a bunch of engineering effort. Then when it turns out to be wrong (because no crystal ball), what do they do? Another big bet to try something else. Tons of waste and opportunity cost.
• 16 May 2020: Said differently, it's a question of how much design space your team can cover per unit time. The less space you can cover, the more you need a crystal ball to pick the right things to do. And crystal balls don't exist.
• 16 May 2020: If a designer has an idea, and it takes 3 developers to try it out, even one revision is going to be a very hard sell. If a designer has an idea, and they pair with one programmer, and they see results quickly, they can iterate more to find what works.
• 16 May 2020: It's about cost and risk. The steeper the ratio, the more the designer has to be "right" because the cost from getting from designer's idea -> built reality is too high. The shallower the ratio, the more you can design a little, implement a little, taste, and repeat.
• 16 May 2020: @_swanson @dhh Interesting. Shaping could help in a situation like that. People easily get caught in the extremes of debating an abstract idea vs. fully implementing it. Shaping improves the discussion by putting real work on the table (the < 20% of the final work that comprises the keystones.)
• 16 May 2020: Yeah. Though the effective measure isn't the buying (hiring of designers) it's the integrating.
• 16 May 2020: https://twitter.com/yaneerbaryam/status/1261450240030388226?s=20
• 16 May 2020: Unnecessary complexity in tech is a tax. You can afford to pay the tax if you compensate in other ways. But you're still paying it.
• 16 May 2020: Take-aways from a town hall Zoom with @yaneerbaryam and @nntaleb today: Two concepts to get beyond indefinite lockdowns in US: 1. Localism — States are too big. Set policy at city scale. Centuries of prior art. 2. Zones — Free travel w/in green zones, like a dynamic Schengen.
• 16 May 2020: We don't prefer Rails, HTML-over-the-wire, monoliths and hybrid apps just out of taste. We prefer them because they massively increase our productivity-per-programmer and enable that 1/2 designer/programmer ratio.
• 15 May 2020: I'm guessing this has a lot to do with the tech stack. Unnecessary microservices and/or unnecessary front-end heavy tech like React. These kind of things make the stack taller, requiring more dev labor for the same surface area. https://twitter.com/rjs/status/1261443696538480640?s=20
• 15 May 2020: Just got an email from a Shape Up reader... "I currently work on a team of 2 designers and 15 devs" I'm seeing this ~ 1/10 ratio of designers/programmers more often than I expected. At Basecamp the ratio is more like 1/2. Very different world.
• 15 May 2020: Been using Trello for this kind of thing for years.
• 15 May 2020: Recorded a 60 min walkthrough today of all the early exploratory work-in-progress for BC4. Documenting what it's like to be deep in the early digging and forging stages. Good fodder for future case studies if we follow through on any of these things. (No bets placed!) pic.twitter.com/OAXsuZ2cif
• 14 May 2020: That's exactly what I was hoping to find! I also like that better than the block version. Thank you.
• 13 May 2020: Also feel free to reach out with questions. Here or DM.
• 13 May 2020: "what can I do to better learn how to operationalize the method for my work situation?" Actually, a better answer: try it. Trial and error will teach you more than anything.
• 13 May 2020: What enables one to "grow the building" — beautiful phrase. https://twitter.com/wrathofgnon/status/1260461317598650368?s=20
• 13 May 2020: Thinking about doing a series of live streaming workshops in the near future. I'll announce here if that comes together.
• 13 May 2020: Delightfully in-depth discussion about the ideas in Shape Up in this podcast from a team that makes learning and development software: https://twitter.com/Emerald_Works/status/1260165293881602050?s=20
• 13 May 2020: It says "there will be copy here and the copy plays a functional role in the concept" per the shaping identifier. Leaving it blank doesn't send as clear a message.
• 12 May 2020: Experimenting with greeking text while shaping. Separates the intent of the copy from the actual copy so the teams have more room for making decisions. We do this in fat-marker sketches by drawing squiggles. Using http://www.blokkfont.com in OmniGraffle for similar effect here. pic.twitter.com/FCDcqGhsuO
• 12 May 2020: I would love to get to that. I am capturing a lot of WIP for BC4 to create the possibility to do case studies on it.
• 12 May 2020: The real data isn't the bullet points. An interview is like a feature film: gigabytes of data. Times ten for ten interviews. The bullet points are cliff notes back to the key moments in the film. There's still a huge difference between reading the cliff notes and seeing the film.
• 12 May 2020: If you want more people to share in the understanding the research gave you, the way is to take them along on the interviews. Then they eat with you and get the taste of it and can understand what the synthesis points back to.
• 12 May 2020: Back to the food analogy... that explanation won't actually help someone who didn't do the research themselves. They didn't eat it. But it will help me to reload all that context back into my brain to make a recommendation or shape a solution.
• 12 May 2020: That way, if/when we decide to work on recurring to-dos, I can pull up the explanation of what people are trying to do and what matters and why bother doing it. Lastly, I do keep transcripts for my own reference so I can search for specific language as needed.
• 12 May 2020: ... the causal theory that we come up with as a result of the research is the thing I document. Eg. "We get requests for recurring to-dos. Here's what I've understood about the situation someone is in when they ask for this and what they're trying to do."
• 12 May 2020: Yes. First, as a baseline, I consider research more like food than information. The people who benefit are the ones who eat it, and if you leave it on the shelf, it rots. Taking pictures of the food etc doesn't do much. The research is an input to a theory-building process...
• 12 May 2020: RT @rjs: OH: "The tickets aren't the work. The work is what delivers against the intent of the pitch." SO GOOD.
• 12 May 2020: OH: "The tickets aren't the work. The work is what delivers against the intent of the pitch." SO GOOD.
• 12 May 2020: OH: "There's more focus on what you're trying to achieve than how. It's empowering for the designer, and it gives more context to the whole squad."
• 12 May 2020: OH: "It can feel odd for an engineer to not have a ticket to work on during scoping, but it's good to get into that habit of dedicating time to scoping. Figuring out the unknowns and continuing to help de-risk is the best thing engineering can do in the early phase."
• 12 May 2020: One good hack for large companies: Reframe appetite as effort weeks vs. calendar weeks. At Basecamp, bets are contiguous weeks in a cycle. In orgs where interruptions are harder to avoid, still huge gains from capping # weeks effort on a bet even if they aren't contiguous.
• 12 May 2020: Listening on a call of a Fortune 500 company that's adopting Shape Up across their digital teams. Amazing to hear the intense focus on appetite, guard rails, scope, and delivering lower fidelity design earlier. Also interesting to hear adaptations they're making for large scale.
• 12 May 2020: Lastly, #1 can happen at macro or micro levels: We can interview customers about why they bought or left the product, and we also interview about context/outcome around a specific little feature or complaint. The macro gives context for the micro.
• 12 May 2020: At the same time, good insights and struggling moments can surface in #3. So we want to be convex to those. Pay attention, don't require any immediate action by default, but whenever interesting, dig deeper to learn and come to a new understanding.
• 12 May 2020: We try to avoid just responding to everything that comes up in #3. You will always hear about what doesn't work at the edges. If you put all your time into the edges you can optimize things that only benefit a small number and then cause losses for the majority case.
• 12 May 2020: Sometimes we'll see issues in #3 that we don't understand. And years will go by and suddenly we'll have the context to make the bell ring and go "Oh ... that's what that's about. We should really fix that."
• 12 May 2020: #3 isn't valuable on its own ... requires digging to figure out what is actually going wrong or where the opportunity is. So when something comes in that's interesting in #3 we apply #1 to investigate and understand it.
• 12 May 2020: #1 is done by product strategy and goes directly into our model of the product and market. #2 is when we screw up and there's uproar. Rare but happens, and then we remedy asap. #3 is the trickle of problems/requests from vocal minorities that come in via support.
• 12 May 2020: I haven't formalized this before. Here's a first shot. "Customer feedback" takes different forms. Three stand out to me: 1) Product strategy interviews (interrogates) customers to learn causality 2) Customers overwhelmingly complain about something 3) "Minority rule" feedback
• 12 May 2020: We don't do user testing. User testing is what you do when you don't have clear measures of quality earlier in the design process. Instead we do deep work to understand the problem and context up front and then design against that.
• 12 May 2020: "Parity to the legacy system is a misleading goal." Bingo. That would be a refactoring. Refactorings have no value on their own. It's about the new place you want to go. You want that to drive the process.
• 12 May 2020: If I don't know Squarespace like the back of my hand, there will be surprises and challenges in the adaptation. On the other hand if I'm a true expert in Squarespace, I could shape the Squarespace version from the start and delegate it production-mode style. Depends on opacity.
• 12 May 2020: For example, suppose I've built a custom site in Wordpress and I want to transition to Squarespace so that a less technical team can make structural changes. The design options on Squarespace may not map 1-1 to Wordpress. So some reshaping is going to be necessary. 1/2
• 12 May 2020: Yes. The reason for R&D phase is opacity. If you don't know for 100% fact that the new platform is 1-1 isomorphic to old, there's opacity. ∴ do an R&D phase where you mix implementation with on-the-fly reshaping to adapt. Once keystones are set, fill in w/ production mode.
• 12 May 2020: Shape Up assumes small cross-functional teams (~ 3 people). We have four teams at a time working in parallel this way (two web teams, two mobile teams). The key is to keep teams small and projects orthogonal. If projects have interdependencies across teams it breaks down.
• 12 May 2020: Two informative dimensions: - Number of new cases - The direction of the change (increase vs. decrease) Shows at a glance where we stand and where it's getting better/worse. https://twitter.com/yaneerbaryam/status/1260010284023873537?s=20
• 12 May 2020: Learning that what we called "epicenter design" in Getting Real is what Taguchi called "primary function." The point is to solve interdependent problems in the right sequence.
• 12 May 2020: Question from @zamith : "How do you apply Shape Up to the very start of a project? What if it is a small team (3/4 people)?" Answer (thread): https://twitter.com/rjs/status/1259338296171192321?s=20
• 11 May 2020: First evidence of this is how people have reacted with surprise upon seeing this page: https://www.endcoronavirus.org/states Very different from looking at US as a whole. Helpful, but still one scale too large to map to personal experience. /cc @normonics @yaneerbaryam
• 11 May 2020: Eg: As people judge whether to tighten or loosen their lockdown behavior, they look around to make the call. If your town seems under control, but cases are rising in your state, the data looks dissonant. Seeing another town marked red would better inform.
• 11 May 2020: IMO big missing piece is we can/should reframe testing as multi-scale red vs green. Today we measure individuals positive/negative, and measure nations as ready to reopen or not. Can abstract as red/green and apply at all scales: individual, town, region, state, country.
• 11 May 2020: The way to balance is to shape the solution at the right level of abstraction. Work out the big pieces, but leave lots of room for the teams to decide on the final form. https://basecamp.com/shapeup/1.1-chapter-02
• 10 May 2020: Right, the upgrade doesn’t have value unless you get something out of it. It doesn’t have to be a new feature. It could be removing a security vulnerability. That’s technically a behavior change.
• 10 May 2020: If by “purely technical” you mean no behavior change, that would be a refactoring. We never, ever, schedule time just for refactoring. Refactoring is part of implementing new behavior.
• 10 May 2020: We keep the whole cohesive by thinking about the whole when we make decisions on individual bets. We can only act on one piece at a time. Re: “purely technical” IMO this is a false category. If there’s behavior change that affects customers, it’s on the table for pitching.
• 10 May 2020: We followed this same process for our new product, HEY. @jasonfried , @jonasdowney and @dhh spiked the core in some early cycles of R&D. Once the concrete was pored, they flipped to production for a number of cycles with two parallel design/dev teams. Now approaching clean up.
• 10 May 2020: All these phases apply equally well to very small teams. I'm doing a small side project right now. I went through two cycles of R&D mode on my own to prove out the idea. Now I'm shaping and two developers are building in production mode to flesh out all the functionality.
• 10 May 2020: 3) At the end, before shipping v1, there are a lot of random screws to tighten, bugs to fix, and unexpected things we realize we forgot. We like to dedicate one or two cycles before launch to doing all these small things without formal pitches.
• 10 May 2020: 2) Once the core architecture is settled and we can see how the main moving parts work, there are a million details and supporting features to fill in. Now we can shape and delegate the work to other teams, per standard Shape Up. We call this "production mode."
• 10 May 2020: 1) In R&D mode we mix shaping & building together. We don't know what we want yet. There will be too much scrap if we try to delegate. It's more about building to learn and establishing the architecture than building shippable features. We bet time, but not on a specific shape.
• 10 May 2020: We go through three phases for getting to v1 of a brand new product. This is at the time scale above cycles: 1) R&D 2) Production 3) Cleanup
• 10 May 2020: People went into lockdown before they were told by anyone to do it. This is a bottom-up thing. https://twitter.com/nntaleb/status/1258931279317405696?s=20
• 10 May 2020: Exponential growth lives and dies by one number: zero. Anything above zero quickly multiplies out of control. At zero, nothing grows. Use containment to get to zero. Then testing and tracing to squash new outbreaks back to zero. https://twitter.com/yaneerbaryam/status/1259300589407735808?s=20
• 9 May 2020: It's a simple concept. Sounds complex because of the jargon. I looked into BC's notification functions through a quality lens and saw losses — people get too many notifications at the wrong time. I'll consider sharing the pitch if it gets to that point; it'll be plain English.
• 9 May 2020: I've been using OmniGraffle on Mac + Notability on iPad. Not perfect, just what's working at the moment. Still prototyping.
• 9 May 2020: We use six weeks. See: https://basecamp.com/shapeup/2.2-chapter-08
• 9 May 2020: Haven’t written it yet. Will consider sharing.
• 9 May 2020: I draw those in Notability on iPad and airdrop them in to OmniGraffle on desktop. Would love to have one tool for all this on iPad but a good option doesn’t exist yet.
• 9 May 2020: The above is work product, not a presentation. The presentation will take the form of a pitch, which walks through the concept in a narrative form and makes the case for betting on it.
• 9 May 2020: Finished shaping. Broke out into six main systems, two of which are flagged nice-to-have (~) in case there's too much work for the appetite. pic.twitter.com/6RwKVrapdh
• 9 May 2020: We think of it like load bearing structure. When you remodel the house, you can't just take away certain pillars or walls without it all falling down
• 8 May 2020: Specific pieces of the code. For example, the way we handle access (who can see what) in Basecamp is concrete. It's a very fundamental part of the code that isn't going to change, and it constrains how we do other things.
• 8 May 2020: Another value that gets overemphasized, along with "reuse", is "change." Some parts of the system should be hard to change. We call that "concrete" at Basecamp. The more important metric is easy to improve. What are the parts that we need to experiment with vs what are fixed.
• 8 May 2020: Programmers advocate for design principles like Single Responsibility Principle on the basis of reuse. The deeper reason for SRR is quality, not reuse. Defining 1 signal → 1 response lets you tune the system to improve response. Can't do that if it does 1+n different things.
• 8 May 2020: In product teams, time is the currency of trust. Give a team a whole block of time (eg. 6 weeks) to deliver something. Undivided time, not sliced up, with a wall at the end (no extensions). Then they give back that block of time well-used by delivering. https://twitter.com/rjs/status/1258822972959125504?s=20
• 8 May 2020: Distinguish red and green zones. Only open travel to/from green zones.
• 8 May 2020: It's beautiful. I love how he defines quality as loss, and distinguishes it from variety of function. Eg the color of the shirt (variety) versus whether the color runs in the wash (quality).
• 8 May 2020: This is what UX is supposedly about, taken to a far deeper level of rigor.
• 8 May 2020: Already on page 7 he blows my mind w/ this challenge: "List and describe the functions of a product with which you are involved. Select what you think to be the most important function and consider what losses are caused by variability of that function." https://twitter.com/rjs/status/1258856467798474752?s=20
• 8 May 2020: Found the best introduction to Taguchi's thinking so far—in his own words, translated from Japanese. pic.twitter.com/2wxEtRy1in
• 8 May 2020: His review here: https://medium.com/@johnpcutler/review-notes-shape-up-2c2bde31fc8a
• 8 May 2020: Nice focus on trust in this piece on Shape Up by @testdouble . https://blog.testdouble.com/posts/2020-05-04-shape-up/ pic.twitter.com/Z4wZAB92H8
• 7 May 2020: Interesting way to reframe environmental problems as urban planning opportunities. https://twitter.com/wrathofgnon/status/1024815347617038337?s=20
• 7 May 2020: (That's my way of understanding it: through the movement of an agent. Maybe @ole_b_peters can improve if that definition is too narrow.)
• 7 May 2020: It's a question of the relationship between an agent and a space of states. In an ergodic system, all states are visited. It's a question of "when, not if." Non-ergodic systems follow unique paths; they don't visit every state. It's a question of "if, not when."
• 7 May 2020: So sorry, Yaneer. Deep thanks to her for planting the seed of the aspiration to improve the lives of everyone. May it only strengthen and grow.
• 7 May 2020: Sounds theoretical. I have good friends in Texas. Have you ever tried telling a Texan what to do?
• 7 May 2020: Really good question. It's looking unlikely that mobility behaviors or enforcement are going to tighten further in the US so we need other ways to look at the problem.
• 7 May 2020: Btw this is the path I took. I skipped college and learned hands-on tech and design skills from people who were further along than me. Then in later years studied more history, math, etc because I had context to value them. https://twitter.com/rjs/status/1258190995478306818?s=20
• 7 May 2020: Exact same here. I did terribly in calculus in high school because there was no motivation for it. The teacher just presented it as a bunch of stuff to memorize. In my 30s I put hours and hours into understanding the concepts because I realized I needed them.
• 7 May 2020: 55:46 "My ideal would be... You go to high school. You learn technical skills and some theory. Then you practice as an apprentice for 5-10 years. And then you go to school. And what you'll learn in school after will be vastly more useful than what you learn in school at age 21."
• 7 May 2020: Thanks for the share. Curious — where's the point in the book where you stopped and thought "I'm going to share this even though I didn't finish it yet" ?
• 7 May 2020: "Harvard is like Vuitton. They make luxury goods [ ... ] Do they deliver knowledge? No, it’s like a Vuitton bag. Maybe it’s better than a $20 bag you buy smuggled from Chinatown but is it worth $10k?” Great talk by @nntaleb on knowledge vs. know-how. https://youtu.be/XFryKZEGzVI?t=1010
• 6 May 2020: Yeah. When we identify it as a different animal, we can treat it differently.
• 6 May 2020: CEOs/founders have a legitimate right to push things top-down. Helps to recognize this is a fiat project, not something empirical. You can't push back with research if they just want to see it happen anyway. Better to strengthen the other bets and advocate for them.
• 6 May 2020: CEO pet projects are a reality and will be on the table. Better to incorporate them into the process than try to push them out. Best to trade them in the open against other potential bets. I called them "strategy by fiat" in this piece: https://discourse.learnshapeup.com/t/what-about-strategy/34/3?u=rjs
• 6 May 2020: Also doesn’t have to be so extreme as “bad actors.” Can also just point to where the problem happened, for a variety of reasons—distraction, mixed communication, unclear expectations, mismatched skill, etc.
• 6 May 2020: That’s a feature, not a bug. The structure highlights bad actors. When everything is chaos you can’t debug. When you shape and bet, and the project fails, you can ask: Was it a hole in the shaping? Was it a problem in the execution? Did someone cross lanes and steal resources?
• 6 May 2020: C depends on the context. Teams should expect C to happen in the R&D phase before you release a v1. It’s learning. After v1 is shipped, if C happens more than rarely, something is wrong upstream.
• 6 May 2020: A) Is rare for us. Happens most if we’re on unfamiliar tech. B) Is covered in Shape Up (see Chapters 8 and 13). C) Happens quite a bit in the early R&D phase of a product. We have to build to learn. The experiments are worth the price when we control the costs.
• 6 May 2020: Not sure what “throw a project out” means. Three possibilities: A) Intervene and cut the cycle short. Almost never happens. When it does, it’s due to poor shaping. B) The team doesn’t finish, which trips the circuit breaker. C) The team finishes but we decide not to ship it.
• 6 May 2020: The issue of capping our downside is fundamentally different from setting the right strategic target. We need to do both. You can have a great strategy and blow up because you couldn’t ship soon enough. You can have a bad strategy and recover if your bet is short and you learn.
• 6 May 2020: Scratching your own itch is a viable path (it worked for us). The point of shaping is orthogonal. None of us have a crystal ball. We make the best strategy we can. But no matter what, we shape and bet to cap our downside and prevent open-ended development that spirals out.
• 6 May 2020: Yeah Shape Up is about capping the downside and shipping. It's not about figuring what is going to be valued by customers. For that, I would start with Competing Against Luck. And then there's more we can try to articulate about the demand side of early shaping work.
• 6 May 2020: When you reframe it as capping your downside, everybody has the same incentives. Nobody wants to waste time and money. So you place more careful bets. That's what shaping is about. You don't just throw time at an idea without knowing where your spending ends.
• 6 May 2020: It's not about being calm. It's about using your time wisely. We did this for v1 of Basecamp when @dhh only worked ten hours a week. When we only had ten hours, we had to use them well. That meant shaping first and placing bets deliberately.
• 6 May 2020: Snap them up with you can. They're getting hard to find. "Battle"—IMO his best case study—is going for $150+ used on Amazon now! https://www.amazon.com/dp/0199898073/ref=cm_sw_em_r_mt_dp_U_fUWSEb69RFC46
• 6 May 2020: Eg. The floor of a house might seem static but it's performing the function of support. The color red on an interface might seem static but it performs the function of calling attention.
• 6 May 2020: Basically nothing static exists. We relate to things as parts of the whole by what they do and how they change.
• 6 May 2020: Everything at every level is or performs a function. Even the elements of the 2D design are there because of what they do.
• 6 May 2020: Right because you're doing the actual work in the medium (code). Git is just a camera to take snapshots. This prototype is an attempt to "code" both problem and solution aspects of a WIP design. Turns out to be helpful cuz there are too many things to hold in our heads anyway.
• 6 May 2020: This is a cool project. Reminds me of Christopher Alexander's structure-preserving transformations.
• 6 May 2020: That's something I've been experimenting with in the format above. Still not there, but it's an early prototype.
• 6 May 2020: This puts demands on the medium and the process though. Eg you need the right primitives and the ability to move them very quickly at the speed of thought and discussion.
• 6 May 2020: If you have to figure out how to re-tell everything as a second step, it's not worth it. Because the history is like insurance. You can't pay too much for it. But if you tell everything through the medium in the process of working it out, then the insurance can come for free.
• 6 May 2020: IMO this boils down to a subtle but important distinction. If we do the thinking in the medium, it's easy to snapshot. There's no step two. But if we do the thinking outside the medium, we have extra steps of figuring out how to represent it and putting it into the medium.
• 6 May 2020: Stubbing G2 and G3. The concept starts to get sharper. (Reminder: I don't know if we'll actually build this. This is shaping, not betting.) pic.twitter.com/2mZ22pMCID
• 6 May 2020: More questions arising, presenting trade-offs. About to make a call and then all the red will go away. Wishing the tool for doing this would record all intermediate states to "play back" all the decisions and revisions to explain the concept later. pic.twitter.com/fi7St3zJ3l
• 6 May 2020: Sometimes we see the "middle" of a piece of design first, and draw it. Othertimes we don't know the solution but we do know the walls around it—what it should do and not do, where it might fit in. Then we draw the walls for it and leave the middle to fill in later.
• 6 May 2020: Defining spaces where some functions can happen. Discovering questions along the way. Note how different this is from a wireframe. Shows the unknowns and holes. Mixture of requirements and solution. Communicates a whole thought process, not just the output. pic.twitter.com/zYryI5t5f0
• 6 May 2020: Vision is good and exciting. The difference is whether your vision must succeed to survive or if you buy the option to try your vision at a survivable price.
• 6 May 2020: Starting to populate the right side... pic.twitter.com/avZtnO7qmf
• 6 May 2020: Bets, not goals. Huge difference between reaching for a target vs. capping your downside and taking each winning as a winning. https://twitter.com/dmbriguy7/status/1257818199854325760?s=20
• 5 May 2020: When @bmoesta and @michaelbhorn wrote "Choosing College", some book reviewers didn't get it. The authors took it as a sign of success. The reviewers weren't "in the job" so they couldn't relate. Meanwhile people in the job raved about it. Major issue with review sites, btw.
• 5 May 2020: Nice thing about targeting a job-to-be-done is you don't have to serve everybody. You can identify who isn't your customer and happily recommend a different solution instead. https://twitter.com/rjs/status/1257819152649121797?s=20
• 5 May 2020: When nobody is shaping the outcome, and an engineering team has to keep building against changing whims or availability, a pure scrum approach is actually a better fit. Shape Up is about product teams being more deliberate about where they want to go and getting there.
• 5 May 2020: Kent Beck's work was a huge influence. Main difference: XP comes from a world where you work for a stakeholder/client who doesn't know what they want, and you have to change all the time. Shape Up is about how product teams set a direction, get there, and ship on time.
• 5 May 2020: This approach is multiscale. For example, we can set a hard outer boundary on BC4. Appetite: four six-week cycles. Inside that, we can define the first cycle of work. There's latitude for future cycles, latitude inside the one cycle, but also clear boundaries + expectations. pic.twitter.com/jsmbPxy4NF
• 5 May 2020: Talked about this on @david_perell 's podcast last week at 19:57: https://www.perell.com/podcast/ryan-singer-design-and-consciousness pic.twitter.com/IbGAU6ROqT
• 5 May 2020: The whole scrum universe is based on hard middle, soft walls. "Let's decide what to do two weeks at a time" with no clear boundary to bump into. Need the back-pressure of the outer wall at a more macro time scale to make trade-offs. https://twitter.com/rjs/status/1257808477956616192?s=20
• 5 May 2020: We need the outer wall to give us constraints so we make trade-offs. There's always a million ways to make things better. We need a forcing function to tell us when to stop.
• 5 May 2020: Good requirements tell you when you're done, not what to do.
• 5 May 2020: Two very different kinds of requirements. Are the requirements specifying the walls or the middle? Are we fixing what it should "do" or what it should "be"? Major implications on (a) amount of latitude for the designer and (b) our ability to control scope. pic.twitter.com/RZ2ouyp8w8
• 5 May 2020: It's very important to question what level of detail a requirement requires. I like to think of this as the hard walls and soft middle. Illustrations: pic.twitter.com/ayEVW8rtm6
• 5 May 2020: Seen as a value-network, it's a question of where to draw the boundaries between problems that have to be solved as interdependent pieces and which can be solved as modular pieces.
• 5 May 2020: That composition maps to what the old 2004 piece called "chunks."
• 5 May 2020: Items on the left can compose. For example it may be that a single function on the solution side should satisfy S1, S4, S5, and S6 because of interdependencies. When I design a piece of solution on the right I can label that (S1 • S4 • S5 • S6). Mapping needn't be one-to-one.
• 5 May 2020: Yes exactly, they serve as requirements/acceptance criteria. Important nuances: 1) It's not a one shot left-to-right. I will find holes in the requirements by trying to solve on the right. 2) Requirements often specify "be" not just "do." Limiting to "do" gives design latitude.
• 5 May 2020: Items on the left are in no logical order. They're in the order I think of them. ~ means nice-to-have, not necessary. Identifiers allow me to make placeholders on the right side without spelling everything out at once in a single sketch.
• 5 May 2020: Breadboards or fat-marker sketches later fill in the space on the right. The list on the left is never perfect or comprehensive. Sometimes by sketching on the right I see things missing on the left. That's "flipping spaces" — from what it should 'be' to what it should 'do'.
• 5 May 2020: Lately, before I start breadboarding or fat-marker sketching, shaping looks like this: a list of things the system should do. This technique goes all the way back to this 2004 piece: https://37signals.com/papers/introtopatterns/ The difference is we're clearer on what "bits" are: they're functions. pic.twitter.com/xeXI3UQ7Td
• 5 May 2020: Then the grouping is a matter of aggregating up from individual stories to larger patterns that have the same basic cause-and-effect chain.
• 5 May 2020: Not sure what you refer to with “generative research.” When I do customer interviews, I try to learn the cause and effect of what they did. What situation were they in, what were they trying to do, what would indicate to them that they reached the outcome they wanted.
• 5 May 2020: Shaping is applicable whenever any team decides to take on a particular project and bet a time box on it. But those teams are less explicit about it.
• 5 May 2020: I can’t get into much detail because I’m not involved in SIP’s, work. Broadly speaking their work, like Ops, has a routine aspect (reviewing exceptions, failures, slow queries) and a ticket-like aspect (responding to issues that arise.) Shaping is primarily for the produt teams.
• 4 May 2020: Highly recommend Making Things Work by Yaneer Bar-Yam. https://necsi.edu/making-things-work
• 4 May 2020: The Taguchi books are helping too. pic.twitter.com/qlWQp2qk95
• 4 May 2020: Talking with @bmoesta lately has felt like Karate Kid. He tells me to paint the fence and then a week later I go "oh ... these notification settings are totally doing the wrong thing!"
• 4 May 2020: Starting to envision a CAD tool for shaping. Not for simple projects. For hard projects, there's no fast malleable medium to capture and aggregate functions into wholes. Eg. 54 systems in Basecamp tied to a project I'm doing. Now composing/factoring into a few primary systems. pic.twitter.com/UF3PeqFIbF
• 4 May 2020: #1 — Own trade-offs Product can only do what they have time carved out to do. When C-level doesn't agree on priorities, product gets pulled in many directions. #2 — Explicit biz model Clarify if you have a "product" or if you're custom-building for clients. You can't do both.
• 4 May 2020: YouTube recording: https://www.youtube.com/watch?v=6KUzLrf27EI Or podcast version: https://rework.fm/product-strategy/
• 3 May 2020: RT @yaneerbaryam: Overwhelming data says opening prematurely will increase cases, escalate loss of life and economic harm. Countries that a…
• 3 May 2020: The story is in the shape of the curve, not the absolute numbers.
• 3 May 2020: Different problems need different experts. Medical experts know about health. That's a totally different problem than understanding the connectivity of people and the spread of disease. Herd-immunity advocates, growing in US, are funded by big $$$ with weak science ala GMOs.
• 3 May 2020: This graph is severe. Shows the US isn't taking serious collective action. The countries who are winning treat covid like ebola, not the flu — something to stamp out, not live with. Need to amplify voices of pandemics experts like @yaneerbaryam . If you can help, get in touch. pic.twitter.com/CqkooewsXY
• 2 May 2020: “ If there was an award to that person or company that did the most to help restaurants during the crisis … It would be for Tock.” Tock remodeled its app in just six days. Awesome story of innovation under pressure. https://www.bloomberg.com/news/articles/2020-05-01/reservations-app-pivots-to-takeout-to-keep-restaurants-running
• 1 May 2020: In other words, the context someone is in as an advisor is different from the context someone is in as a decision maker. To be better advisers we need to understand the context better.
• 1 May 2020: To scientists, understanding is everything. In real life, knowledge is just one piece of the problem. There are social and political anxieties to overcome. The way to unpack is to talk to someone who's in the decision-making position to understand the forces they're under.
• 1 May 2020: That book (The End of Average) is very accessible and short. A more technical version from Peter Molenaar is here: https://twitter.com/rjs/status/1103819606001704960?s=20
• 1 May 2020: Averaging together can’t show you causality. Here’s a good book on that: https://www.amazon.com/End-Average-Succeed-Values-Sameness/dp/0062358367/ref=nodl_
• 1 May 2020: When you know what metrics matter, you can run metrics on the ensemble. When you don’t know what the metrics are, look at the time evolution of one story and dig for the causality.
• 1 May 2020: Look at one subject’s time-evolution to understand causality. Then you can run metrics on the ensemble to size what you saw (ie. “how often does that happen?”)
• 1 May 2020: There’s a huge difference between looking at one causal story with a million data points vs a million stories each with a few data points.
• 1 May 2020: Yesterday I plotted 2d histograms of 50k+ users to try to understand Qs about number of participants per Basecamp project. Today I looked at the time-evolution of one project that over time had 1, then 5, then 55 people. One project’s time-evolution answered all my questions.
• 30 April 2020: An expanded version of those guidelines: pic.twitter.com/9fNhDqcubn
• 30 April 2020: That's a fantastic display.
• 30 April 2020: One of my favorite data viz principles from @EdwardTufte is "show causality." Here's a small-multiple display of countries that beat Covid-19, with an explanation of the actions they took in the box at top right. Fully matches @yaneerbaryam 's advice. https://twitter.com/endCOVID19/status/1255971365733179398?s=20
• 30 April 2020: Interesting thoughts on “post-publication peer review” from @stephen_wolfram 's latest update on his physics project: https://writings.stephenwolfram.com/2020/04/the-wolfram-physics-project-the-first-two-weeks/#what-about-peer-review-and-all-that /cc @ole_b_peters @researchersone
• 29 April 2020: Very pleased to see it. More than I expected. Most interesting is how companies pick and choose which parts to adopt. Starts to sketch the lines of modularity on what was originally a wholly interdependent system.
• 29 April 2020: We need to record a podcast or something with @bmoesta on this. There are books but none of them touch the essential points very well.
• 29 April 2020: That's referring to work done by noise, not noise factors. (The diagram is directly from one of Taguchi's books).
• 29 April 2020: Today at 11am Pacific, 2pm Eastern. https://twitter.com/rjs/status/1254138619352121346?s=20
• 29 April 2020: That talk was a prototype. More thorough explanation is now available in our book Shape Up: http://basecamp.com/shapeup It won't work for everyone but hopefully it will give you some new ways to think. Seeing many companies adapt parts of it into their own ways of working now.
• 29 April 2020: The cycle work is the only work. No interruptions from anywhere to do other work. (Pulling in for a short discussion here or there is ok.)
• 29 April 2020: Everything takes time. At our current size and with our culture, we're mostly happy just to ship something. That's the big success. The rest is stuff that we may or may not have to do, and it's a little more slapdash.
• 28 April 2020: It's not something we put a lot of attention to or process around. We have very little documentation (almost zero). Mostly rely on code (very readable, beautiful code) as documentation. In some cases our data person sets up analytics. But often not and no standard process.
• 28 April 2020: For example, we could (probably should) instrument the "mark as read" button as a separate event.
• 28 April 2020: That's something we could measure to improve the signal/noise metric.
• 28 April 2020: I don't have to evaluate the next step, whatever that is, if I've understood the cause-effect structure correctly and the step I control produces the right outcome.
• 28 April 2020: So going back to the Someone's Activity Report... if I understand what somebody uses that report to do, I can set requirements on what output the report has to produce to enable that next step.
• 28 April 2020: For example, somebody retrieves history from Basecamp to defend themself in a lawsuit. I don't need to measure the outcome of the lawsuit. I can measure the functions that put history on the record and make it retrievable.
• 28 April 2020: We don't have to measure the final effect. In the Taguchi method we define control factors and noise factors — things we control "inside" and things we don't. We set quality metrics on our system based on the effects they produce down the line outside the system.
• 28 April 2020: It could be that some things are easy to instrument, and others require more expensive field research to measure. Let’s see. Very early in all of this. All of the prior art (as far as I know) is outside of the software field.
• 28 April 2020: I believe it can be applied to everything. Everything we build has a function, which means it produces changes from input to output. Which means there is some difference in the world that matters to look at. Some things might be harder or easier to measure, but that’s secondary.
• 28 April 2020: In fewer words, maybe there is a way to switch the framing from disposition of people to “disposition” of circumstances: trends in the dynamics around a person.
• 28 April 2020: Wonder if this feedback loop suggests that some people could produce sequences of decisions that could be characterized as dominantly conservative or daring (naively type A) but the trend traces back to the accumulation of circumstances (type B).
• 28 April 2020: This opens an interesting line of inquiry about the inputs to the function. Eg. LML’s discounting paper. The circumstances (initial wealth, payment amt, timing...) are inputs. Some inputs are present-moment: payment amount. Others accumulated from past decisions: initial wealth.
• 28 April 2020: In examples like these, it might help to contrast two ways of thinking: A. Conservative / daring describe decision-making functions. Ie one person’s “way of deciding” is conservative. B. Conservative / daring describe decisions output by a general decision-making function.
• 28 April 2020: We could learn, for example, that what people are trying to see there and what we’re showing aren’t the same. That could define a new metric. But there are too many layers of unknowns without doing the interviews first.
• 28 April 2020: I’m still learning. First I’d wrap the report in context by doing customer interviews around it. From the interviews I’d pull out the intent and outcome — what happens that makes someone go there, and how do the know when they are done.
• 28 April 2020: Time to think about usage metrics differently. If Toyota was a software company, they would count how many times people press the brakes. "Look, engagement is up!" What they do instead is measure what the brakes do when they're pressed. https://twitter.com/rjs/status/1254956591645749248?s=20
• 28 April 2020: Haven't written that up yet. Lots of discussion of that here, both at the beginning and end: https://www.youtube.com/watch?v=6KUzLrf27EI
• 28 April 2020: https://www.youtube.com/watch?v=6KUzLrf27EI
• 28 April 2020: Note how our (Basecamp's) accounts in the graphs above are less noisy than overall customer usage. This maps directly to opportunities to improve the product to make it more robust to different use cases.
• 28 April 2020: The key is to measure a function the product performs, not the number of times an event happens. This example clicked it for me: a brake system. Signal is when the response matches the intent: stopping force. Noise is squealing, wear, vibration. Source: https://www.amazon.com/gp/product/0071347828/ref=ppx_yo_dt_b_asin_title_o05_s00?ie=UTF8&psc=1 pic.twitter.com/ru46vP0848
• 28 April 2020: Breakthrough using Taguchi methods to measure the quality, not amount, of usage. 1. Define what the app should do as signal → response. Here, you notified someone → they read it. 2. Define quality metrics. Here, read vs ignored. 3. Measure. pic.twitter.com/134f4tzMXd
• 27 April 2020: I recommend Competing Against Luck by Clayton Christensen as the first starting point: https://www.amazon.com/Competing-Against-Luck-Innovation-Customer/dp/0062435612 Then to learn interview technique, a workshop w/ @bmoesta or this online course: http://learn.jobstobedone.org/courses/JTBDinterviews
• 26 April 2020: Ideally something we can use in future cases. Global connectivity means this won't be the last time we need to deal with a pandemic.
• 26 April 2020: Also would be nice if the term could express the fact that these boundaries cut across political boundaries, rather than map to them 1-1.
• 26 April 2020: Might help if these new boundaries have a name that makes them easy to talk about. Above nation/state boundaries, boundaries of safe movement. ("Cordon sanitaire" doesn't roll of the tongue, and it emphasizes closing off rather than opening with a defined edge.)
• 26 April 2020: Yes. Example: https://m.signalvnoise.com/keep-digging/
• 25 April 2020: Did you have to train your team to remember to @ mention clients whenever you need them to see something?
• 25 April 2020: Got it. So keep email notifications on, but only for mentions.
• 25 April 2020: After your clients turn off email notifications, how do they find out that something new happened on Basecamp that they need to see or respond to?
• 25 April 2020: Change notification settings to what?
• 25 April 2020: Re: "we figured out the default intensity of email notifications was the culprit" What did you do to fix it?
• 25 April 2020: Looking at notifications received per user per day from a Basecamp cohort to check assumptions about usage behavior. (Rows are people, columns are days, colored cells are # notifications received. Dates are normalized to account start.) pic.twitter.com/Kkv7COEEbw
• 25 April 2020: The second Shape Up Practitioners Remote Meetup is next Wednesday, April 29 at 6pm UTC (11am Pacific, 2pm Eastern). Organized by @davidarens . Details here: https://www.meetup.com/shapeup-practitioners/events/270244421/
• 24 April 2020: Like most design "frameworks" the double diamond is so abstract it can mean whatever people want it to mean. A clearer process would have inputs and outputs at each stage. For example, what is the input to "develop" and what is the output of "develop"? What does "deliver" mean?
• 24 April 2020: Yeah the double diamond you showed above is mixed up in lots of ways. It conflates defining the problem with shaping in the center, as you said. Then it doesn't distinguish the phases of having a solution shaped vs fully worked out. Among other problems.
• 24 April 2020: Nice.
• 23 April 2020: https://twitter.com/rjs/status/1253136928985059330?s=20
• 23 April 2020: https://twitter.com/rjs/status/1253136928985059330?s=20
• 23 April 2020: That said, let's see how it plays out. It's on a trial run.
• 23 April 2020: Lastly, forging suggests a simple form as the output. Like forging iron into a hook. A good problem definition isn't complex with lots of twists. It's a basic truth like "oh ah ok yeah so that's what matters here." Shaping can be more nuanced (multiple screens, steps, etc.)
• 23 April 2020: And the image of intense heat and pressure contrasts nicely with shaping, which for me invokes more an image of sitting at a potter's wheel.
• 23 April 2020: Had to ship and I liked it from the gut the most. Thinks I like about it: 1) It invokes an image of raw material 2) It invokes intense energy and effort 3) It invokes an end product (not just digging, but creating)
• 23 April 2020: Agree. Every name had downsides so picked one that sounded best and had enough of the right connotations. We’ll see how it plays out.
• 23 April 2020: Yes.
• 23 April 2020: When you can wrap the problem with intent -> outcome, and contrast the current undesired outcome with a different desired outcome. The function that actually delivers the new outcome is undefined. Filling that in is shaping.
• 23 April 2020: (But no bets until the first cycle comes.)
• 23 April 2020: A few substantial features are shaped already.
• 23 April 2020: Basecamp.
• 23 April 2020: points.
• 23 April 2020: From an internal writeup I posted today. Introducing the distinction between forging and shaping to describe some different projects in play. pic.twitter.com/ZfURAEjJbz
• 23 April 2020: "Forging" has stuck the best so far.
• 22 April 2020: Good metaphor! Looking for a verb (ala "shaping").
• 22 April 2020: Yes I believe that's a sub-function of this step. We do sleuthing to gather more information. Eg interviewing customers. But then we have to analyze the interview to turn what we hear into variables of the problem.
• 22 April 2020: Or worse (and perhaps more common)... having a solution on the table that people want to pursue with no clear problem definition to judge it against.
• 22 April 2020: There's a difference between thinking there's a problem and understanding the problem enough to solve it.
• 22 April 2020: Triage implies prepared options to choose from.
• 22 April 2020: Think in terms of input -> function -> output. A chain of functions: forging • shaping • pitching ... Problem definition is output of forging. Problem definition is input to shaping.
• 22 April 2020: Localism would imply many YouTubes.
• 22 April 2020: This is before shaping. When you aren't actually clear on what the problem is so you don't know what the shape of the solution should be.
• 22 April 2020: I can think all day about why someone complains about ... say ... notifications in Basecamp. If I don't understand the problem, I have to go talk to them and ask them questions. Or learn more about the circumstance they are in to see what goes wrong.
• 22 April 2020: Insufficient. This involves obtaining knowledge about what's true in the world. That's not thinking. That's getting hands dirty.
• 22 April 2020: Good for the first step of this phase. Second step is creating some new order so you can positively state what the problem/opportunity is.
• 22 April 2020: Yeah, for example. I'd abstract lower as: the person doing the research has to convince someone the research matters later. It doesn't feed directly into an active decision-making setting.
• 22 April 2020: Yeah get to the empirical why not the fiat why.
• 22 April 2020: Yes but IMO belongs more to shaping, the step that comes later.
• 22 April 2020: Importantly, it can also go the other way. We have a hunch that we want to build something, and we need to work backward to find the friction points or struggles so we can understand if what we want to build is right or not.
• 22 April 2020: Spot on.
• 22 April 2020: Super impressed by the thoughtfulness of the responses of so many people on this thread. Thanks for digging in. https://twitter.com/rjs/status/1252778234401316866?s=20
• 22 April 2020: Modeling the problem.
• 22 April 2020: "Modeling" — totally.
• 22 April 2020: I think in the most interesting cases we don't have the data because we don't know what the variable is yet. We have to actually work to figure out what data is even the right data to help us understand the problem better.
• 22 April 2020: Beautifully said.
• 22 April 2020: No. https://twitter.com/rjs/status/1252778234401316866?s=20
• 22 April 2020: The motivation is to draw more contrast between when people do 'problem framing' by just talking vs. when they do it by digging hard into the problem to understand it.
• 22 April 2020: Yes. Down one order. I'm looking for the work you do to accomplish problem framing.
• 22 April 2020: Very well said and agree. Though to my ear "capture" sounds passive, like clicking a camera shutter.
• 22 April 2020: Improved!
• 22 April 2020: "Smelting" is right on (extracting metal from ore) but not very pretty.
• 22 April 2020: Mining is good. Archeaology suggests the artifact is already there to be found. The artifact gets constructed later in the shaping step.
• 22 April 2020: Good ones.
• 22 April 2020: Good to bring in the question of divergence. This step is both divergent and convergent in the sense that you have to converge on a diagnosis.
• 22 April 2020: Diagnosis is good.
• 22 April 2020: I like to think of the latter part of shaping as the subtractive step. Because you have the clay on the table. This early problem formation part feels positive in the sense you're constructing an understanding.
• 22 April 2020: Very good.
• 22 April 2020: Good aspect but too passive. Effective customer interviewing and digging into the problem requires asking the right questions.
• 22 April 2020: If you want to be right you have to dig harder to figure out what the actual variables are that matter.
• 22 April 2020: Research is soft and leisurely when it happens lower in the company. The atmosphere around learning and problem definition is completely different when you feel you have to crack the nut because resources and decisions ride on it. ... vs. hoping someone reads your report.
• 22 April 2020: I'm talking about the work you do to get to a problem definition.
• 22 April 2020: Good but soft. Sounds leisurely. In practice, this kind of work is expensive and time has to be carved out for it, which means there's a kind fo pressure to unearth something valuable. If I line up ten customer interviews in a week, I'm leaning in hard to learn. Not exploring.
• 22 April 2020: Discovery is a noun, not a verb. It's a thing you get. not a thing you do to get it. Consider what you have to do to discover something. You have to search. To dig. To question.
• 22 April 2020: "Digging" / "unearthing" is closest so far.
• 22 April 2020: That's a helpful one for the contrast it introduces. Annealing implies you already have the starting material and you are strengthening it. This is more like digging out the raw material upstream from that.
• 22 April 2020: RT @MarkWhiting: @rjs Sure. I feel like it sits squarely within new product development but I don’t know of a nice term that captures those…
• 22 April 2020: https://twitter.com/rjs/status/1252779954091118592?s=20
• 22 April 2020: Unearthing — Very good one.
• 22 April 2020: Difference in real life is the checkpoints don't exist. You have to fight to figure out what the actual checkpoints are that you should even navigate to! It's the diff between solving a problem and figuring out what the variables even are.
• 22 April 2020: "seismic" — don't know what to do with that but cool and very evocative.
• 22 April 2020: Exactly.
• 22 April 2020: A theory is the output, not the process. I'm talking about the work you do to get to a theory.
• 22 April 2020: This is more like the hard earth you dig into and the muscle you put in to dig. Eg interviewing customers who complained about a feature to understand what is actually the problem.
• 22 April 2020: Soft. It's not about ideation. It's about wrestling to get the facts about what actually matters, what impacts people, where people are struggling.
• 22 April 2020: Good angle. I think it's more about the exploring than the mapping. The hard part is being in the wilderness alone, not the pen and paper documentation of what you saw.
• 22 April 2020: Very often "prioritization" problems aren't about moving ideas up and down a list. They are about relating ideas to an understanding of the real world. It's the f(x), not the x. Once you see the relationship to the real world, it's easier to make the calls.
• 22 April 2020: Coming up with ideas isn't hard. Finding empirical truth that gives weight to the ideas is hard. (And valuable.)
• 22 April 2020: It's not about ideas, it's about not knowing empirical truth.
• 22 April 2020: Helpful but agree, too close. Forming/shaping is like the wet clay is on the wheel. This is more like digging out of the ground with hard tools.
• 22 April 2020: I think appetite is a step later because it refers to the appetite for solving a certain problem. In the earliest stages we can't even see what the problem is yet or where the opportunity lies.
• 22 April 2020: Reframing suggests you had a frame to begin with. Demand-side research is harder — you literally don't know what the variables are or where the bounds of the problem are and you dig to find them. Like being lost and trying to get oriented.
• 22 April 2020: Refinement comes much later. This is when you don't even have your hands around the biggest coarsest chunks of the problem.
• 22 April 2020: Way too soft.
• 22 April 2020: Research isn't something soft and exploratory we do when we're bored or curious. It's something expensive and intense we do when we don't understand something, and we're willing to make the hard trade-off to spend time learning about it.
• 22 April 2020: The "forging" step (whatever we call it...) is the most uphill of the uphill work. It's trying to understand what's not working. Or why customers do something we don't understand. It's where demand-side research happens.
• 22 April 2020: Before pitching a project, there's shaping it. Before shaping it, there's this really hard work where you struggle to define the problem or the opportunity. Need a word for that. It's not fluffy brainstorming / ideation. More like "forging." Hard work, concentration, heat.
• 21 April 2020: This review of the iPad Magic Keyboard is classic @gruber . It's not just a product review; it's good writing. He opens with a unique story and a distinct focus (the strength of the hinges). https://daringfireball.net/2020/04/the_ipad_magic_keyboard
• 20 April 2020: Next step is learning to interview. Here's an online course: http://learn.jobstobedone.org/courses/JTBDinterviews Best is in person. Webinar/workshop w/ Bob is the way to go.
• 20 April 2020: We could do a Q&A at the end. There’ll be more interesting exchange if you’ve all gone through the material first. DM me to work it out.
• 20 April 2020: We consider all kinds of things. :) Gotta make trade-offs because we can’t do it all.
• 20 April 2020: Our Ops team has a Confluence account for that.
• 20 April 2020: There are tons of things we don’t have and would like to have. Gotta make trade-offs.
• 19 April 2020: Nothing to do with BC4.
• 19 April 2020: Interesting... the one other app I've seen that does this kind of thing is also a screenwriting app.
• 19 April 2020: So many people share the itch too. There’s something here.
• 19 April 2020: Yes you did! This was supposed to be a side project! :)
• 19 April 2020: The concept addresses that. Allows you to just write normal text and then with on operation ref-ize it and write a new alternate. You are never in pure abstractions unless you specifcially want a placeholder (“intro goes here.”) A spike will show if it works in practice or not.
• 19 April 2020: Yes. It’s all text mode. The refs just partition the text into different spaces. You navigate in three dimensions: up and down a text, in and out of refs, and left and right across alternations.
• 19 April 2020: And time is very different for version-control vs option-comparison. Version-control can be slow. It’s about safety and recovery. Option-comparison happens at the speed of decision-making and creativity. “Let’s try this...” “Is that better?” Requires very different design.
• 19 April 2020: Based on early experiments I believe the same approach may work for alternate versions of sketches and diagrams as well. Text is a special case. https://twitter.com/rjs/status/1251927254088560640?s=20
• 19 April 2020: Git is bad at this. Besides the obvious interaction problems, branching isn't multi-scale. (You branch a repo, not a line of code.) Comparing branches is a special difficult operation, not an all-day normal way of working.
• 19 April 2020: It's hard to name things until you understand them well. Lately I've found it helpful to use identifiers in the early stage of a design, while things are still moving and I'm not sure where the boundaries are or what things should do. pic.twitter.com/DgEkfwQdoU
• 19 April 2020: This is what "pattern languages" are really about. "Patterns" are named problem/solution pairs. "Language" is the composition of patterns into greater wholes.
• 19 April 2020: You know you have a product concept when the product becomes a language you can speak. "From a composition, select text to substitute a ref and define the first alternate." "Tap them on check-in to see their board. Stick a message, they get notified -> takes them to the board."
• 19 April 2020: This is very different from version control. It's not about future and past. It's about multiple options accessible in the same present.
• 19 April 2020: In this model a "ref" (S1..Sn) is something that the text is supposed to "do" independent of what it "is." Eg "explain what a ref is." Idea is to set a bound around an unsolved piece of text and make substitutions within that bound without messing up anything outside of it.
• 19 April 2020: Looks doable using content attachments in Trix. Going to experiment.
• 19 April 2020: Progress turning the writing idea above into an app concept. Alternate versions of compositions, blocks and inline text are substituted in the main text via reference symbols. Any text is a composite of plain text and referenced text. References can be used anywhere. pic.twitter.com/UV0vAczgbX
• 18 April 2020: Reminds me of this quite good episode of EconTalk about the lack of supply of small sq foot housing, boarding houses, etc. Lots of potential to help people on the low end of the market. https://www.econtalk.org/jenny-schuetz-on-land-regulation-and-the-housing-market/
• 17 April 2020: It makes falsifiable predictions. Whether the tech exists to perform those experiments yet is another question.
• 17 April 2020: IMO the most exciting thing about @stephen_wolfram ’s new theory is it could change how physics is taught to beginners. That’s because it makes known physics derivable from new simpler primitives. @ole_b_peters ’ work has this property too for economics.
• 17 April 2020: Online education is really having a moment. Not only can you get content you won’t get anywhere else, you can get it from the very best people in the world. https://twitter.com/rjs/status/1251241015152762880
• 17 April 2020: Wolfram is live streaming a version of his new fundamental theory of physics ... for kids! The amount of fantastic things coming from Wolfram's group lately is inspiring. https://www.youtube.com/watch?v=c9L-tRdPolM
• 17 April 2020: Thanks. We’re thinking about doing a video series on Shape Up in the near future. ( http://basecamp.com/shapeup )
• 16 April 2020: Key point https://twitter.com/normonics/status/1250850575597568000?s=20
• 16 April 2020: That's right. There's a level of work above and around shaping to figure out what's worth pursuing. Then that's what you shape.
• 16 April 2020: Nice introduction to the idea of shaping in this piece: https://medium.com/kolonial-no-product-tech/reviving-the-pre-project-c06b9fbd6805 pic.twitter.com/jKraWMCDqK
• 16 April 2020: Depends on the job the student is trying to get done. (see https://www.edsurge.com/news/2019-09-19-how-choosing-a-college-is-like-buying-a-milkshake ) pic.twitter.com/CyF9bszxAa
• 16 April 2020: @sliteHQ calls it a "regroup" period.
• 16 April 2020: These false universals are easy to shut down when you reflect on them... But go in a meeting room and propose adding three extra steps to a signup funnel. You'll get tons of pushback from people saying more steps is bad and fewer steps is good.
• 16 April 2020: Simple example.. a false universal is more people will respond to a survey if you make it shorter / faster. For a Shape Up workshop, I screened applicants with long essay questions. Intense engagement because the questions were relevant and helped them frame their progress.
• 16 April 2020: The design community really struggles with #6. If you understand it, you have a super-power because you can make trade-offs other people aren't willing to make.
• 16 April 2020: Yeah there's overlap. This list was off the cuff. The point of #1 is learning to separate the two and some notation to keep them apart when get conflated in discussions with others. (New stuff). #6 is more about hammering against false universals. Eg faster isn't always better.
• 16 April 2020: ... more like forming some thoughts for what could maybe become a book in a few years :)
• 16 April 2020: And another one: pic.twitter.com/bfx2yG3Yme
• 16 April 2020: Jane, our data person, created a web-accessible dashboard. It pulls from server logs and a custom-built event tracker.
• 16 April 2020: Nice to see this steady interest in Shape Up. About 5k unique visitors a week. pic.twitter.com/E9TiL4Tgwi
• 15 April 2020: Notes on the Synthesis of Form Ch. 2 gives a good definition. Competing Against Luck touches it from a business angle. No good definitive reference yet for designers.
• 15 April 2020: I think apprenticeship / pairing with someone more experienced is the best way to really learn this stuff.
• 15 April 2020: Domain-Driven Design is particularly good for finding the right abstraction based on understanding the problem, not universal principles as you mentioned.
• 15 April 2020: Best books I know for that: - Kent Beck: Smalltalk Best Practice Patterns - Martin Fowler: Refactoring - Eric Evans: Domain-Driven Design
• 15 April 2020: Q: What's the "fundamentals of design" book you wish existed? A: https://twitter.com/rjs/status/1250525002505392128?s=20
• 15 April 2020: Instead of "here is good design," it would teach how to make design choices. How to use a compass instead of telling you were north is. Something like this off the top of my head. pic.twitter.com/zdtkZV6Iud
• 15 April 2020: Form and function is the wrong dichotomy (I know that's heresy!). Better frame is function vs. fitness.
• 15 April 2020: I would avoid all the Bauhaus-type stuff. It's based on fashion and universalist dogma instead of contextual fitness.
• 15 April 2020: Highly recommended these two follows if you're into human-scale and human-centered architecture (as opposed to architect-centered architecture): @wrathofgnon and @CharlestonArchi
• 15 April 2020: The Tufte gives good concrete tips about styling, and helps frame the thinking-process a design enables. ‘Notes’ gets you thinking about contextual fitness instead of absolute shoulds/should-nots (common problem for designers). Norman introduces basic interaction concepts.
• 15 April 2020: The book I wish existed doesn’t. Here are a few books that inspired me when I first started: - Tufte: The Visual Display of Quantitative Information - Alexander: Notes on the Synthesis of Form (esp Ch. 2) - Norman: The Design of Everyday Things
• 15 April 2020: Using "partials" can help: https://discourse.learnshapeup.com/t/breadboarding-simplify-with-partials/98 This makes it easier to spell out parts of the UI that might be context-dependent by naming and extracting them. In general though, if a UI has conditionals in it, I would first try to design them away with a diff approach.
• 15 April 2020: pic.twitter.com/kJDUg835rM
• 15 April 2020: Inspiring how @stephen_wolfram bootstrapped his new physics work by building tools and designing visualizations and a language to explore his ideas. "I generated thousands of screenfuls of visualizations . . . what I was doing here was a kind of zoology" https://writings.stephenwolfram.com/2020/04/how-we-got-here-the-backstory-of-the-wolfram-physics-project/#oh-my-gosh-its-actually-going-to-work
• 14 April 2020: I meant to describe above what ends up happening, not what should happen.
• 14 April 2020: Unique how @stephen_wolfram integrates design into his scientific work. pic.twitter.com/AdGU93LuHe
• 14 April 2020: Wolfram is live streaming about it right now: https://www.twitch.tv/stephen_wolfram
• 14 April 2020: Interesting new perspectives on time and causality in here. https://twitter.com/stephen_wolfram/status/1250063808309198849?s=20
• 14 April 2020: Another one. pic.twitter.com/h39EqXLeQ5
• 13 April 2020: Aha. Anything stick out in your memory from the podcast that made the light bulb appear?
• 13 April 2020: Good observations from @HarryDCrane about the necessity to act without data. (a) Data only tells you about the past. (b) In many situations you can't afford to sit around waiting for more data. Applies to bet-placing in product development too. https://twitter.com/CorneliusEcon/status/1248859675770191874?s=20
• 13 April 2020: Guessing Slack wasn't calm for quite some time before making the change to Basecamp. What changed so that one day came where you said ok, today's the day?
• 13 April 2020: Awesome. Thanks for entertaining those questions. Helps us to learn. Glad to hear that it worked out.
• 13 April 2020: Was it the kind of thing where, once you went remote, the communication was there but the accountability for following through on tasks wasn't?
• 13 April 2020: Re: “make things actionable” — how did you do that before you went remote? Meetings at the office?
• 13 April 2020: Why go back? What changed to make now the time after so long?
• 13 April 2020: So cool to hear. Anything in particular that you told people to make that culture shift happen? Anything you can share about what you stopped doing now that you’re in Basecamp and what the group does differently?
• 13 April 2020: Excellent summary of the first half of Shape Up by @jackivers https://thinkfractional.blog/shape-up-your-agile/ pic.twitter.com/k2WuhC9S8w
• 13 April 2020: Yes. iCloud File sharing starts to come close to this (copied from Dropbox).
• 13 April 2020: Anybody else noticing more public Google Docs going around during lockdown? Increased demand for web publishing at the low end of the market. Good example here via @kottke . This "Board Games" doc is almost a web site. But don't need Squarespace for that. Love this kind of thing. pic.twitter.com/yfSGYcUZUz
• 13 April 2020: Custom built.
• 11 April 2020: Glad to hear it. Would be curious to hear any details about what changed.
• 11 April 2020: Twitter’s search field stores past searches so it’s a quick way to jump to peoples’ feeds that I like to check occasionally.
• 11 April 2020: Time and attention are precious.
• 10 April 2020: Key point: Jobs is not just a conceptual thing. You can’t ask “what’s the job?” and fill in a box. Jobs are empirical things to find in nature. You can’t make them up. To find them, learn the causality of struggle->shopping->purchase and interrogate people who bought.
• 10 April 2020: Next step is seek out training/workshop/live talk by @bmoesta to get hands dirty with practice.
• 10 April 2020: Yeah. Here are two good starting points: Book: https://www.amazon.com/Competing-Against-Luck-Innovation-Customer/dp/0062435612 Podcast (conference talk by @bmoesta and @chriscbs , who I learned from): https://anchor.fm/business-of-software-podcast/episodes/What-Is-Jobs-To-Be-Done-eaap9h
• 10 April 2020: Probably some parallel to be drawn to work-constraint cycles here: https://twitter.com/rjs/status/991352103015735296?s=21 https://twitter.com/rjs/status/991352103015735296
• 10 April 2020: IMO helps to consider two broad classes of action in a knowledge representation: detailing and structuring. You as cursor are “somewhere” in the representation. From “here,” add info at/below current scale: detailing. Or add info above current scale: structuring. (Recursive)
• 10 April 2020: Glad to hear. Quite a few podcasts linked on http://basecamp.com/shapeup that talk through those concepts of imagined vs. discovered tasks, assigning at the scale of projects instead of tasks, etc.
• 10 April 2020: Re: hierarchy, it’s intersting that many outliners prioritize adding children over adding parents. Adding parents is cumbersome: first add a new larger scale bullet that stands alone, then select and indent/move the lower scale bullets below. Should be one “chunking” operation.
• 10 April 2020: Hope it helped. The live stream format is tricky because you can’t see how the questioner is reacting to the answer and whether you’ve hit the question properly or not.
• 10 April 2020: Packing is about adding information at larger scales that hides information at lower scales. Hierarchy is one way. Add parent/child relations, then fold children out of view. Links are another. Put info behind a link and it’s folded behind the link name. But diff trade-offs.
• 10 April 2020: Yes. Re: "unstructured" — links are structure. Different type of structure than folders. Bottom-up vs top-down. IMO still counts as "packing" in the sense that I don't just capture + dump, I capture and lightly structure.
• 10 April 2020: Been thinking of this has two functions: capture and pack. We often talk about "unpacking" things. "Packing" is as important — relating info together in a contained structure that we can unpack later when relevant.
• 10 April 2020: Agree. It lowers the bar to putting things in because you don't have to figure out where they belong first.
• 10 April 2020: The cost of doing it and the things that are currently working that could break.
• 10 April 2020: Don't separate. Biz makes bets according to how the three fit together: what we know how to build, capped downside we will risk, and our theory of what people want. Don't need hard goals/targets to do that.
• 10 April 2020: Projects are much more fun when you allow yourself to be pleasantly surprised by successes than when you have to chase targets. Big reason to bootstrap whenever possible.
• 10 April 2020: Key point from today's Q&A: Instead of trying to quantify the upside of a project, quantify and cap the downside. (What @nntaleb calls convexity.) Then, given survivable and similar downside risk, pick the best idea based on your understanding of what users are trying to do.
• 10 April 2020: I draw them by hand in Notability on iPad and then screenshot to share. You can make them in a tool like Whimsical (use the Wireframe mode) but IMO it's not worth the trouble. Most diagramming tools take too many clicks and too much time.
• 10 April 2020: I'm live now with @jasonfried talking about Product Strategy at https://www.twitch.tv/basecamp . Ask questions with #AskJFRS
• 10 April 2020: Made it up. It's a naming convention for systems (functions) and control factors. Still experimenting with all this.
• 10 April 2020: Tried searching for washable masks on Amazon. Unlike pre-corona Amazon, no Prime icons, no clear winners in the results. Then Googled, found a "best-of" list featuring independent e-tailers, and ordered from one. Got a "shipped" notification same day. Win for decentralization?
• 9 April 2020: No. Fitness is how you compare functions.
• 9 April 2020: A big part of that is about reducing the number of things you need to learn to start using the system, which at the second order demands less time and concentration of your team when you ask them to adopt it.
• 9 April 2020: Yes different metrics for different circumstances. First requiring more time but less recall. Then requiring more recall and less time.
• 9 April 2020: We can try to make things "easier" by making them faster: one-click from the home page, and reducing recall by labeling them more. But then we'd increase the demand on concentration by putting more things to parse on one surface!
• 9 April 2020: Answering these questions requires us, the designers, to understand more about the context to make the right trade-offs explicitly.
• 9 April 2020: Consider Emacs. It's far faster (time) to do things in Emacs than many other editors. But this comes at the cost of memorizing lots of commands (recall).
• 9 April 2020: A challenge for designing UI: We often say it's important you "can" do something in an interface. Or that it's "easy" to do something. But "can do it" and "easy" aren't metrics for testing fitness. Is it a matter of: Time it takes to do X? Knowledge? Concentration? Recall?
• 9 April 2020: "Unwanted details" in the sense of they added extra detail you didn't want, or they made choices on the details that are different than the choices you would have made?
• 9 April 2020: Bring your questions about Product Strategy to this livestream tomorrow at 1pm central with me and @jasonfried . https://twitter.com/basecamp/status/1248314715799007234?s=20
• 9 April 2020: Yeah so maybe 'unbundling' isn't the right term because it's not necessarily about splitting these roles into different people. More like factoring ... getting clear what's in the package so people can reach for the right skills as needed.
• 9 April 2020: Good question. What I’m seeing anecdotally is a lack of clarity from the hiring side (“We need a UX person” comes up in response to a broad range of issues) and a lack of clear segmentation on the supply side of training/skill acquisition. Result seems to be a lot of mismatching.
• 9 April 2020: Bob, have you seen any cases where understanding of the jobs scaled in the org? Is scaling the same problem as hand-off?
• 9 April 2020: I'll likely share more once I understand it better myself. Like Alexander, his work isn't directly applicable to today's context. Will take work to first understand and then translate.
• 9 April 2020: Rails makes it small. Tech stack is a huge factor.
• 9 April 2020: Sorry nothing to recommend yet.
• 9 April 2020: Total lockdown vs Pareto lockdown. Interesting possibility from @nntaleb . https://twitter.com/nntaleb/status/1248048589181419520?s=20
• 9 April 2020: See http://basecamp.com/shapeup for more detail on this.
• 9 April 2020: Expanding: 1. The designer doesn't wait for a programmer to become free. They are together in one time pool. 2. Nobody can interrupt any of them to do something else. 3. They aren't tasked with open-ended discovery, nor micro-managed with how to execute the detail.
• 9 April 2020: Broadly speaking, we have self-organization at Basecamp via these conditions: 1. All roles needed to do the work are in the same team 2. They have no time commitments outside that team & project. One focus together. 3. The work is shaped: boundaries of in/out, latitude inside.
• 9 April 2020: Then, yes, different structures have different trade-offs. I think the question you raise is about the trade-offs: when self-organization is a good thing and how to make it happen. That's a big subject.
• 9 April 2020: By functions I didn't mean "functional team" — that's a specific org structure. I meant the steps that have to happen as dictated by the actual work, regardless of who does those steps. It's helpful to untangle that.
• 9 April 2020: Innovator's Solution has a good chapter on it.
• 9 April 2020: Different job.
• 9 April 2020: Yes also part of Kano. That excitement quality migrates down to performance and basic quality over time.
• 9 April 2020: Clay Christensen treated this in his work on Modularity and Interdependence. It's a rich subject.
• 9 April 2020: Yeah companies aren't cookie-cutter. Gotta look at the dynamics of who is actually defining what work to do, who decides how time gets spent, etc to unpack.
• 9 April 2020: Eg. maybe a PO is supposed to set direction for the product. But then sales is saying "we promised to do X for the new client." The one doing the shaping is actually sales in that case, and the PO is relegated to a coordinator or Tetris-player.
• 9 April 2020: But that's a generalization. Best is to do the functional decomposition on a specific case ... say ok what's the work that needs to happen here and who is doing what aspects of that work. The work is the same, but the division into roles is firm-specific.
• 9 April 2020: Practically speaking, I believe PMs tend to do more coordination and calendar Tetris so that a mandate from above happens at a layer below. PO in theory refers to setting direction, but POs often don't own the resources or have time to think so they end up acting like PMs.
• 9 April 2020: If I understand Kano right, Spotify's ability to keep playing new, good stuff after an album ends is "excitement" quality. Not something I expected, not something I measure performance by, but something that makes me go "wow" and increases satisfaction.
• 9 April 2020: https://twitter.com/rjs/status/1248051024503267328?s=20
• 9 April 2020: At Basecamp, our designers bundle styling, interaction design, and front-end dev. That is, they can make something look good, make it understandable, and make it work up to the boundary with the back-end. https://twitter.com/rjs/status/1248040548796993538?s=20
• 9 April 2020: Titles come and go with fashion. But the work that needs to be done to make a thing work belongs to the work itself.
• 9 April 2020: A good way to debug performance in some part of an org is to do the functional decomposition, ignore everybody's supposed roles and responsibilities, and then ask: Who's actually performing which function? Who's better at which function? Which function is missing?
• 9 April 2020: Functional decomposition is different than organization design. That is, the types of work that have to happen != who works for you and what title they have and who else they work with. Because one person can perform a different mix of functions.
• 9 April 2020: Decomposition affords recomposition. Unbundling "UX" or "Product" doesn't mean you can only do one of the things. It's about being more choiceful and conscious as you decide what kind of work will create the forward motion you want in the moment you're in.
• 9 April 2020: Another one to unbundle: "Product" person. Do you... Coordinate other peoples' execution? Play calendar Tetris to hit targets given from above? Decide what to build next? Own resources vs. lobby someone who does? Design/build solutions? At what level of abstraction?
• 9 April 2020: @bmoesta can probably explain this point about outsourcing research better.
• 9 April 2020: That was an off the cuff unbundling from the POV of building software. I'm sure there are more and better ways to slice it.
• 9 April 2020: Outsourcing research works when a high-level decision maker is stuck at a crossroads. It needs to be expensive and go straight to the top. Research at lower levels just piles up as unused inventory.
• 9 April 2020: Real branding is the accumulation of past actions. Your brand is the reputation you earned because of what you did over and over again.
• 9 April 2020: "Product Owner" rarely means shaping. Usually means playing the whip and calendar Tetris to get mandates done with too little time/people. "UI Designer" rarely differentiates styling from effectiveness.
• 9 April 2020: You'll often see someone suggest a vision redesign. Everything looks good. Then it gets implemented. Now nothing can change. This is extremely costly. Short term gain, long term loss.
• 9 April 2020: Styling seems easy to outsource but this is a mistake. The implementation side of it is very undervalued. Styling decisions affect structure. The structure enables or impedes future changes. Choice of how templates, CSS, block relationships work is important and takes expertise.
• 9 April 2020: No good primer is out there unfortunately. The three books I recommend to start with are either Notes, Battle, or Timeless Way. But I realize that doesn't help much.
• 9 April 2020: Stylists who can build out the work (HTML/CSS, JS, CMS/static site generators, etc) are and continue to be more valuable than pure graphic designers who want to work on something interactive.
• 9 April 2020: Prediction: We're going to see an unbundling of "UX". People hiring will ask: Am I trying to improve how it looks? -> Styling ... offload roadmapping/project definition? -> Shaping ... figure out what customers value? -> Research ... implement interactions? -> Front End Dev
• 9 April 2020: Taguchi's signal to noise ratio is a formalization of the concept of goodness of fit that applies to deterministic systems.
• 9 April 2020: What Alexander called "misfits" in Notes ch. 2 maps to Taguchi's loss function. It's the variation in the context (aka noise factors) that causes a problem in the response.
• 8 April 2020: Really leaning back and enjoying the isomorphism between Alexander and Taguchi. What Alexander called "choosing the context" of the form/context boundary maps directly to defining noise and control factors for a signal -> response function in Taguchi's work.
• 8 April 2020: Most people working in "complexity" see it as a class of problems, not a field. The class of problems has a corresponding set of common tools. What's interesting is these classes of problems and tools cut across fields.
• 8 April 2020: Good reference: https://necsi.edu/why-complexity-is-different
• 8 April 2020: See @yaneerbaryam 's work (physicist, not a mathematician). Defines complexity as cases where standard tools don't work: calculus doesn't help because of discontinuity, statistics doesn't help because of patchiness, etc. Renormalization group is a model positive example.
• 7 April 2020: One takeaway: A shift to remote work means a shift to focusing on outcomes, not hours in the chair. Some people are effectively on paid vacation since going remote and this is a red flag about their contributions.
• 7 April 2020: Incredibly thoughtful conversation with @bmoesta on what shelter-in-place means for businesses, short-term/long-term impact and unknowns. Plus deep observations on how remote work changes the way performance is evaluated and how we measure time spent. https://overcast.fm/+Gh8LSIWjM
• 6 April 2020: Kathy Sierra has amazing work on this. All about what's the unit of progress I can make in this specific time block I have. What do I do at this time that's different from what I do later to get better?
• 6 April 2020: That is, expand from two extremes: easy/hard, dumb/expressive, to a multiscale view: Given a window of time TW1, how much progress can a person make? Then, when TW2, TW3 comes, what can unfold next? Which primitives undergird TW1->TW2->TW3?
• 6 April 2020: Helps to overlay time. Instead of "make it easier", chunk mastery into phases. Then look at which capability is above the surface or below the surface at a given time chunk. Maybe a couple things could be migrated down to earlier and some things migrated up to later.
• 6 April 2020: Very sympathetic to this (love that Rich Hickey video). At the same time, a drum set and acoustic guitar have shallower curves than a violin but still with lots of headroom up to mastery. Maybe a diff conversation can be had about what are the bootstrap affordances to surface.
• 6 April 2020: Thanks. Would be very curious to see/hear what this means in your context doing architecture. Please share something if you get to the other side of translating / implementing something.
• 6 April 2020: Yeah I don't use it for to-dos. I think of it as a way to deal with what already happened, not what's coming.
• 6 April 2020: The use case is analogous to snapping a photo of a whiteboard with your phone before wiping it down.
• 6 April 2020: The former. Describing how I use it as it stands.
• 6 April 2020: So far Roam uniquely solves this because I don't have to decide where to put the info. I just start on Daily Notes. The linking interface makes it fast to link to a new page from there and dump stuff. To find later, I can scroll through Daily Notes or jump to the page.
• 6 April 2020: Update re: @RoamResearch . Been using every 2-3 days for 3+ weeks now. Pattern is: notes accumulate on my whiteboard, TextEdit windows, etc. When it becomes too much and I want to clear it out, need a way to capture that's (1) fast and (2) I trust I can find my way back to it.
• 5 April 2020: A lot has been written on JTBD from different people and yeah there are different takes on it. I just recommend what worked for me and what I use.
• 5 April 2020: My best recommendation to start with is Competing Against Luck by Clayton Christensen. https://www.amazon.com/Competing-Against-Luck-Innovation-Customer/dp/0062435612
• 4 April 2020: I think there's some adaptation work to be done (maybe by us) to translate it into the current context.
• 4 April 2020: Thanks. That material was an early prototype of what became Shape Up: http://basecamp.com/shapeup
• 4 April 2020: Used lightly Taguchi-inspired methods to shape and write an ad today. Systems (functions) with control factors on the left define parameter spaces. Different alternatives (A1..An) from customer research fill the parameter space. Best fit after trying a few combos on the right. pic.twitter.com/vbFBV6KGMU
• 4 April 2020: Thanks for the answer. I’ll take a closer look.
• 4 April 2020: Direct close mentor of my mentor. Never studied his work but assume I'm breathing that air.
• 4 April 2020: A super subtle and powerful tool in this context is from @bmoesta : "what's this more about and less about?" Can cut off huge chunks of problem space and narrow solution space without a quantitative metric.
• 4 April 2020: In many cases we can't use quantitative metrics for design purposes or decision making. But we can be very conscious and intentional about what matters, what doesn't matter, and what we're judging as fit when we approach a decision.
• 4 April 2020: Challenges: We usually don't know what to measure or measure the wrong things. And not every measure is quantitative. The broader definition of having the right measure is "knowing what matters."
• 4 April 2020: Yes and one step more specific than relations: dynamics. Relations over time. Intent -> action -> response -> outcome.
• 4 April 2020: Same basic ingredients as in Alexander's method (form/context/fit) but spelled out to an incredible level of precision and completely operational. Just starting to get my head around it.
• 4 April 2020: A very mature model of "shaping the work" is embedded in the Taguchi method. Signal -> response defines what it does. Noise factors define under what conditions it should and should not be expected to work. Loss function defines fitness as a range of acceptable values.
• 4 April 2020: There's a deep difference between specifying what something should "do" and what it should "be". The most important unknowns in a problem aren't static values to dial in. They are functions. What should it do and what do we look at to know if it did it?
• 3 April 2020: Mind blown by the Taguchi method. Now I understand better why Porsche and Audi are so good. The concept of measuring distance in functional space from an "ideal function" is deep. Figure out what it's supposed to do, don't just make stuff and whack-a-mole problems.
• 3 April 2020: Any interesting examples? I know that design patterns in software and a lot of Beck's work was inspired by Alexander.
• 3 April 2020: Battle is a great example. https://www.amazon.com/Battle-Life-Beauty-Earth-World-Systems/dp/0199898073
• 3 April 2020: Not sure what you mean by operationalized. Alexander built lots of real projects with his own teams and documented them as case studies in his books. It was theory extracted from practice, not the other way around.
• 3 April 2020: Q: How to teach your team about the "appetite" concept? Answer, with a story from 37signals' consulting days: https://discourse.learnshapeup.com/t/how-to-teach-your-team-about-the-appetite-idea-concept/288/2?u=rjs
• 3 April 2020: Improving my design education. Most of what I’ve learned so far came from architecture or software (Alexander, Beck, Evans et al). Taguchi comes from manufacturing: auto industry, electrical systems, chemical engineering. Very different framing and tough real world constraints. pic.twitter.com/c7IzNaDXDN
• 3 April 2020: https://twitter.com/rjs/status/1245930843480059904?s=20
• 3 April 2020: When I turned it on, I understood why it was off by default. Doesn't help.
• 3 April 2020: Turns out it's a preference. Was off by default when I created my user account. pic.twitter.com/FOdFm473wv
• 3 April 2020: I don't see that. pic.twitter.com/91cI9qY5eZ
• 3 April 2020: We solved this in BC3 with the Hey Menu. One single place to go to see what’s new. No hunting. No missing things.
• 3 April 2020: I’ve been invited to some Slack accounts lately for some Covid-related projects. I can’t believe there’s no unified “here’s new stuff you need to see” feed. You have to scan the whole sidebar to hunt for new stuff! Threads are especially opaque.
• 3 April 2020: Box is how much time you give. Gate is when/if you’ll start.
• 3 April 2020: When I tried, the audio recording was full of bizarre noise. Then I checked online and saw reports that it's not supported. Can you detail what "not ideal" means? I'm trying to figure out if this will work or not. Been using ScreenFlow for years. Reluctant to switch but stuck.
• 3 April 2020: Highly recommend any workshop with @bmoesta on how to interview customers. It's how I learned. https://twitter.com/belsito/status/1245112032862617602?s=20
• 3 April 2020: Gating is also a nice way to say "no" without saying "no." That is, "let's hold off on that until X" where X is some condition to be met first. Can be based on dependency (can't paint until the drywall is up) or priority (not until after v4 ships). https://twitter.com/rjs/status/1245867373711609856?s=20
• 3 April 2020: It's not about inaction. It's about doing the right thing now instead of the wrong thing. You can only do one thing at a time. So the sequence matters.
• 3 April 2020: Capping your downside is key to survival, whether it's at the decision level, the project level, or the firm level.
• 3 April 2020: A box is one kind of constraint. A gate is another. A box is a constraint around something versus a gate is a constraint in front of something, on the way to something. Eg. "Let's gate that and hold off until we know that we're even getting the data back we expect."
• 3 April 2020: Less direct example: When someone asks for coaching or mentoring, give them homework first. That way you don't spend valuable hours on preliminaries and you can screen out frivolous requests.
• 3 April 2020: Examples: Spending money on an identity before you have a business model. Worrying about scaling too early (and many kinds of pre-optimization). Debating a design of a feature that won't be relevant unless the unfinished work you're doing now is successful.
• 3 April 2020: Time boxes are well-known ways to increase optionality. Time gates are less-known but very powerful. Eg. when do we wait to do something until something else happens first.
• 2 April 2020: @Telestream Does ScreenFlow support recording audio from Bluetooth headphones yet? Discussion forums suggest it's not possible to use AirPods to record. I don't see a mention of it on the release notes of your newer versions.
• 2 April 2020: I was in and out of today's livestream due to Xfinity maintenance in my area. @jasonfried and I will schedule another solid block for Product Strategy Q&A in the near future.
• 2 April 2020: I'm live with @jasonfried right now. https://twitter.com/jasonfried/status/1245768222256893952?s=20
• 2 April 2020: Basecamp’s marketing story goes back to its launch in 2004. We had a big audience of digital creatives on our blog at that time and Basecamp was targeted right at them. From that foothold it grew by word of mouth.
• 1 April 2020: That's actually how we make product decisions. Winner chooses.
• 31 March 2020: It's a custom-built Python tool called Ginsu. A little bit of detail is available on it here: http://www.feltpresence.com/analytics.html
• 30 March 2020: We’re also convex to feedback in the sense that if we learn something isn’t working, and it’s important, we have the option to make it the top priority in the very next cycle if we want to. That comes from betting only one cycle at a time + the circuit breaker. (See Shape Up).
• 30 March 2020: “Be convex to adoption” means keep the costs of efforts low and allow ourselves to be happily surprised if they spike up as successes afterward.
• 30 March 2020: Sometimes we’ll get a new idea and say “oh people will use this way more if we do X.” But the idea came first. Not “how can we grow adoption?” Adoption is a side-effect of finding the right problem to solve. Rather focus on problems and be convex to adoption than try to chase it.
• 30 March 2020: “Growing feature adoption” — we rarely use this lens. Prefer to look diagnostically for struggles: things that aren’t working, things that aren’t right. Then shape a project around making that thing better.
• 30 March 2020: I think you need to look at this through the structure of the org and how resource allocation happens. For us, marketing is a separate dept from product design/development. If the work involves changing the product, that gets shaped as a project for that team. Ditto marketing.
• 30 March 2020: "The city had a permanent health authority [ . . . ] and an expert in foreign countries, borders, plague and trade." What a great bundle, that role.
• 28 March 2020: Yeah this whole thing applies recursively to itself. Your suggestion about spelling everything out can be taken as the supply. Whether it fits or not depends on the demand context I'm in vs. the demand context you're in. Cheers.
• 28 March 2020: Yeah there are trade-offs. Trying to spell everything out has costs too. The costs I don't like are (1) time and (2) prematurity. I may not understand or see all the relationships up front! I'd rather put down what I know and let the rest fill in through interaction and struggle.
• 28 March 2020: Demand and supply blur into each other at the intermediate scales. They're only 100% pure at the polar ends of the spectrum.
• 28 March 2020: I don't see that as personal interpretation. I see it as a model of what needs to happen from the demand POV and why, with space for filling in how exactly to do that from the supply side.
• 28 March 2020: No. That happens in conversation. Eg "we think we need to establish authority here because someone who's trying to advocate for action needs to show who they're getting this info from and why it's credible." That links the two scales and it's all demand-side.
• 28 March 2020: No. I'm making an effort to spell out the intermediate scales. Eg by putting "establish authority" as a negative shape in there and talking that through on kick-off or explaining it in the pitch.
• 28 March 2020: I would rather leave gaps for struggle and conversation than try to spell completely everything out in advance. It gives me a chance to learn what other people know/assume and, if something is missing, the struggle creates the openness on their side to ask questions.
• 28 March 2020: Between the large scale (laying out the jobs) and the project scale (eg the example I showed, linked again here), conversation usually works. Below that, the team usually has enough context or we workshop as needed. https://twitter.com/rjs/status/1243984192376942592?s=20
• 28 March 2020: I'm not seeing the disagreement. Of course things go in the best way when everyone involved has a clear and common understanding of the functional context at all scales flowing up from the thing they're working on.
• 28 March 2020: If anything is missing and people would have to "fill in the blanks in their heads" instead of with experience, knowledge, context etc then we fill that gap. But that doesn't have to happen in the same place/format every time.
• 28 March 2020: I think we're not using the same words for the same things. I was considering the example I showed above to be intermediate. The relations between what I showed above and the larger scale are talked through with the team or written in the pitch, depending on time/circumstance.
• 28 March 2020: The largest functional scale applies to projects we haven't even thought of yet. It's the outer wall. Between that outer wall and the inner walls of things we've built there's a lot of open space for all the things we haven't done yet. They will be constrained by the jobs too.
• 28 March 2020: So I believe experience is showing that at the intermediate and small scales they should always be interleaved, rather than all one or all the other gathered together.
• 28 March 2020: Or if I'm stuck on a specific design solution, I'll zoom out to the nearest functional scale. The need for the functional requirement (negative shape) arises out of the context of some form problem.
• 28 March 2020: At the largest scale, yes. That's what we do when we work out what the jobs are for the product or the motivation for a feature as a unit. But here at the scale of building something, the purpose of spelling out functions is to make decisions about forms.
• 28 March 2020: Yes. There's shorthand reference to a larger functional scale at the top that was cropped out. pic.twitter.com/mPOT0sOz8s
• 28 March 2020: Here's a very schematic example: https://twitter.com/rjs/status/1241823113349742593
• 28 March 2020: "If your only form of shared documentation is the supply-side product" — not the case. We write shaping documents before kicking off projects to communicate what the thing is supposed to do at different levels.
• 28 March 2020: I try to frame every requirement as functional. If a requirement says what to do, then I have a fitness test to judge whether it does that or not. If a requirement says what to "be", that's not a requirement, it's just design that's already done.
• 28 March 2020: Yes those are examples of functions at an intermediate scale. They aren't fully demand-side (they're describing the supply) but they aren't down in the weeds of how exactly the supply does those things.
• 28 March 2020: Example of two scales: Someone's making a website with policy recommendations re: Covid-19. Say "convince policy makers to order lock downs" is the large scale function. To do that, the home page needs to "establish authority." The latter specifies a smaller piece of the whole.
• 28 March 2020: Excellent thread on preferring the simplest model given the data available: https://twitter.com/alex_adamou/status/1243898659785375745?s=20
• 28 March 2020: @bmoesta has called this split "what it is" versus "what it does."
• 28 March 2020: Form and function are both multiscale. Smaller forms have to fit into larger forms (a button on a form on a screen in a navigation scheme). Smaller functions fit into larger functions (a step in a sequence to perform a job).
• 28 March 2020: Form and function are both orthogonal and dependent. How? Treat function as a space of possibilities in which to embed form. To the extent that multiple forms can fulfill one function there is orthogonality. To the extent the function constrains the forms there is dependence.
• 28 March 2020: Progress on negative/positive shape (which will get new language soon). Thread. https://twitter.com/rjs/status/1243969946075287554?s=20
• 28 March 2020: Yes. The "delete account" button has a purpose and a situation wrapped around it. But that's one step in a larger sequence, connected to a bigger purpose. And of course the purpose of the app is wider than to just delete something. So there's a hierarchy of scales there too.
• 28 March 2020: Yes we need to scale in and out and also "rotate" or "flip" from demand/supply side at different moments in the process to resolve our questions about what is the right fit.
• 28 March 2020: Most people are used to moving up and down in scale along the supply side to make things fit. The key thing I've been trying to describe is moving up in scale along the functional side to embed the problem in a "what does it do" context that then pushes constraints back down.
• 28 March 2020: To do that, we don't look at anything else on the screen. We look at the situation — context and outcome — where the button is relevant. That's a different kind of space "around" the problem to help us make decisions.
• 28 March 2020: The problem is, that approach would never tell you to make the "delete your account" button red when all the other buttons are blue. For that, we zoom out on the demand side of the functionality the button should perform. We look at the context around what it's supposed to do.
• 28 March 2020: Language for this is WIP but bear with me. We can zoom out purely on the supply side of the static structure the thing fits into. Eg make the button match the shapes and sizes and colors of everything else on the containing screen so it's harmonious.
• 28 March 2020: Yes. But your question makes me realize that positive/negative is one step too abstract. Actually there are two ways to zoom out to the negative space that contains and constrains the thing we're trying to design.
• 28 March 2020: When we're working on a piece of a design, and we can’t decide how to make a trade-off (should it be bigger/smaller, stronger/lighter, etc), we don't get anywhere by continuing to stare at it in isolation. To make the decision, we zoom out to the context that it fits into.
• 28 March 2020: "Temperature" (metaphorical name) is a different idea in this context. In addition to pace of change, it's stability of structure. A chat not only moves fast, but whatever structure appears in it disappears quickly.
• 28 March 2020: We're trying to put language and formalism around things experts do intuitively.
• 28 March 2020: This is all supply side. For purpose, we'd overlay a different model on the demand side.
• 28 March 2020: I’m following Christopher Alexander’s lead with this and treating the positive/negative split as fundamental and filing everything under that. (He calls it form/context.)
• 27 March 2020: We can resolve by moving up a level (to the negative). The kick-the-due-date option would have a single comment thread going forward forever. Is that bad? Depends on the context. By shaping the context at the higher level we can make the trade-off at the lower level. 2/2
• 27 March 2020: Example: Shaping recurring to-dos in Basecamp. Do we spawn a new to-do every time, or do we recycle the same to-do by kicking the due date forward upon completion? Those are two positive shapes and we could disagree on which is "better." 1/2
• 27 March 2020: Oh ha.
• 27 March 2020: This is fundamentally what JTBD is about as I've learned to apply it. When I don't know what to do, I move up a level and flip to the opposite space to clarify my requirements. Then I move back down and flip back to make the trade-offs.
• 27 March 2020: I prefer to start in the negative so I don't get lost in the weeds. Start by shaping what this thing is supposed to do without what it is. Define walls between orthogonal aspects of what it's supposed to do. Then fill in. But both work and you can flip back and forth. 2/2
• 27 March 2020: You can start from either side. You can start down in the weeds with a positive shape, hit a fork in the road, scratch your head, and ask: what's the right choice? Then move up to shape the surrounding negative space, embed the positive, and now you see which fork to take. 1/2
• 27 March 2020: Walter Murch is incredibly observant. You'll see (and hear) film in a different way after spending time with his talks or his book (In the Blink of an Eye). This documentary is a great start: https://vimeo.com/401292817
• 27 March 2020: This is an example of multi-scale analysis. I learned how important this lens is from @NECSI . See for example Chapter 4 of Making Things Work: https://necsi.edu/making-things-work pic.twitter.com/THJFArl2Y7
• 27 March 2020: This map can help to show some differences with different collaboration tools from the supply side. For example Slack offers only high temperature. Trello and Dropbox offer only low temperature.
• 27 March 2020: This is one tool I've been using to think strategically about BC4 and beyond. Mapping the space of internal communication situations against "temperature" and scale. Think of temperature like jiggling chaos on the high end vs frozen structure on the low end. pic.twitter.com/Y5zwZwuWWS
• 27 March 2020: Eg "we need a way to start running the algorithm from the current state" is different from "there will be a green 'RUN' button on the top left of the Coded screen."
• 27 March 2020: If they were exactly mathematically inverse there'd be no point in differentiating them. The purpose of the negative space is to narrow down your options but not box you into one solution. The positive shape is a subset of the possibilities in that space.
• 27 March 2020: @kentbeck 's TDD is a concrete example. The implementation is not the inverse of the test. But there is a relationship.
• 27 March 2020: It's not the inverse. The negative defines a "space of possibilities" ( @yaneerbaryam 's term). It doesn't tell you the one thing to do. It narrows down your options. Then the positive is your idea of something that fits into that space.
• 27 March 2020: This negative/positive space thing is already Shape Up 2.0+. The bleeding edge is moving fast.
• 27 March 2020: Yes. Still testing to find the right language.
• 27 March 2020: Sprawl happens in the absence of containing constraints. Much of shaping is about designing those containing walls: What are we not doing, how do we know what's in and what's out. How do we make trade-offs.
• 27 March 2020: The opposite of product bloat and sprawl is coherence. To get coherence, you need more knowledge of the context around the product to push from the outside and define its borders.
• 27 March 2020: Yeah a lot of ideas targeting non-consumption: things people can't do at all today, rather than incremental improvements. And some intense rounds of customer research the past couple years help us see which new things increase coherence instead of adding sprawl.
• 27 March 2020: The interdependent -> modular process is happening faster than I expected. That is, something starts off as one tangled ball of yarn. Then you see how to pull it apart into pieces with explicit interfaces so people can adapt and customize.
• 27 March 2020: Starting to see the outlines of a "Guide to Adapting Shape Up." The book describes our tightly integrated, whole-hog approach. Now successful case studies are showing where teams can bend, break and adjust the system to fit their particular org.
• 27 March 2020: Sorry we don't commit to release dates until we're very close. (We recommend the same to other product teams — there's far more upside in keeping the optionality.)
• 27 March 2020: Community-created content is one of the best indicators that you're onto something. So cool to see @michiels sharing @firmhouse 's implementation of Shape Up in a real world, real work walkthrough here: https://youtu.be/93FYez0UD0w
• 27 March 2020: Fantastic trick from @michiels : When a post on Basecamp has too many questions/bullet points to discuss on one thread, pull each issue out into a to-do on a "Discussions/questions" list. Brilliant. Source: https://discourse.learnshapeup.com/t/show-tell-of-daily-practicing-shapeup-in-your-team/274 pic.twitter.com/Vd0iAIOxCB
• 27 March 2020: So many good things lined up for Basecamp right now. BC4 is going to be exciting and, before that, BC3 is getting even better.
• 27 March 2020: The clustering mentioned in this project is unrelated to hill charts and Basecamp. It’s an analysis step in a customer research process.
• 27 March 2020: Recommended. Lots of insights and thinking tools in here. https://twitter.com/yaneerbaryam/status/1243543505978429444?s=20
• 27 March 2020: Yeah, not much async video. Usually the writing is enough. IMO async video is boring to sit through. We use rare video calls with tiny headcount (2-4 people) to workshop things, not for meetings. That is, to dig into a problem, look at work together, make a call on something.
• 27 March 2020: https://basecamp.com/shapeup/3.1-chapter-09
• 27 March 2020: Experimenting with a more concise, schematic way to present shaped work on a side project. pic.twitter.com/z8hILMwhRr
• 26 March 2020: Thanks, helpful.
• 26 March 2020: Thanks!
• 26 March 2020: Yeah I imagined trying to reduce these dimensionally but I don't know (a) how to apply a distance measure to matrices rather than vectors and (b) whether standard distance measures would capture these differences or not.
• 26 March 2020: Naively (I'm not a math/data guy), I imagine that's the central problem. How to come up with a definition of similarity/difference in a few dimensions to say a given account is more like this or that case.
• 26 March 2020: (Note: We of course imagine the real data to be noisy mixtures of these pure demonstrative cases.)
• 26 March 2020: Any mathy followers interested in this problem? Wondering if it's possible to characterize and count different types of Basecamp usage by comparing matrices like this: pic.twitter.com/K9I6WPiU0J
• 25 March 2020: That is, different answer and solution for each specific definition of who “we” are in that question: we as a nation, as policy makers, as householders, as peers etc.
• 25 March 2020: Probably a different answer at each scale. Would like to understand better so we can help people get through what holds them back.
• 25 March 2020: Buzzing with ideas from the first Shape Up meetup. Seeing new degrees of freedom in the method. Especially around who shapes and when, and how strategy can be set at different levels of abstraction in the org.
• 25 March 2020: The first Shape Up practitioners' meetup was impressive. Very compelling, behind-the-scenes presentation by Mike Bartlett and smart, practical questions from the crowd. Thanks @davidarens . Video here: https://youtu.be/CtcSwlvIIuo Stay connected on the forum: https://discourse.learnshapeup.com
• 25 March 2020: Interdependence for Shape Up would mean you have to do it all the way the book says, as one big lump. Modularity would mean, for example, introducing an option to (a) shape during cool-down like Slite's tribes or (b) parallel to cycles like Basecamp's Core Product team.
• 25 March 2020: For full elaboration see Clay Christensen's work on Modularity and Interdependence. The Innovator's Solution is the best reference. New things start out interdependent — every piece is custom woven to every other piece. Means users can't customize. Then modularization follows.
• 25 March 2020: Mike really knows his stuff. Been around the block, deeply schooled in agile, scrum, the original XP stuff from Kent Beck etc. Went in to Shape Up very consciously. He's showing real, concrete work. Talks about struggles they had and what they did to solve them.
• 25 March 2020: https://twitter.com/davidarens/status/1242529502674259968?s=20
• 25 March 2020: Fantastic presentation from Mike Bartlett of Slite on how they adopted and adapted Shape Up, happening now: http://www.youtube.com/watch?v=CtcSwlvIIuo
• 25 March 2020: It's apparently standard practice in an epidemic, US included, to question people about where they've been once they're identified as positive in order to protect people who may have been exposed.
• 25 March 2020: Idea here wasn't to track the location of people, but to publish the "where have you been" data that gets collected at the point of treatment.
• 25 March 2020: A friend working on an epidemic intelligence team at state level raised the idea of an app to browse anonymized contact tracing data. Shaping session followed: pic.twitter.com/sZATUlVtLK
• 24 March 2020: Good problem to have! Thanks for organizing.
• 24 March 2020: The negative shapes are actually functions. They specify what the positive shape is suppose to "do" instead of "be." Just outlining skips to what it should "be" without describing at a level of abstraction higher what the function/purpose of a block is.
• 24 March 2020: This is WIP. It's negative in the sense of "negative space." It's a shape that is defined from the outside but the internal details are undefined. Still experimenting to find the right words.
• 24 March 2020: The numbers show the order in which I thought of them. The order in which they appear shows my first attempt at sequencing them.
• 24 March 2020: Shaping something like software, there would be another level of abstraction between the negative shape and concrete solution — a breadboard. A 60sec ad is too small scale for that. Sequencing the systems (Sn) and coming up with implementations for them happened simultaneously.
• 24 March 2020: Used some new shaping tooling to sketch a podcast ad for a specific audience. Negative shape specifies what the ad was supposed to do. Iterated on the positive shape until it fulfilled that. Symbols map pieces of copy to their purpose to make feedback discussion more productive. pic.twitter.com/MMoFYGFTNu
• 23 March 2020: I'll also be participating in the Q&A after Mike's talk. https://twitter.com/rjs/status/1242194556008849409?s=20
• 23 March 2020: The first Shape Up practitioners meetup is happening remotely on Wednesday, 7pm UTC (12pm Pacific, 3pm Eastern). RSVP in advance to get the Zoom link. (Organized by @davidarens ) https://www.meetup.com/de-DE/shapeup-practitioners/events/269164841/
• 23 March 2020: This will be good. Mike Bartlett, VP of Product at Slite, has been using Shape Up since before the first draft. He's giving an in-depth talk at the remote Shape Up practitioner's meetup on Wednesday. Details here: https://discourse.learnshapeup.com/t/shape-up-practitioners-remote-meetup/225/6
• 23 March 2020: If that helps, it's good. I think of negative as a concave shape and positive as a convex shape and they fit into each other. Like a mold and a form.
• 23 March 2020: Really nice use of small multiples in this infographic thread from the FT. https://twitter.com/jburnmurdoch/status/1241730634109894656?s=20
• 22 March 2020: This feed is getting nerdier. I hope you don't mind.
• 22 March 2020: It's personal, but not ad hoc. Been formalizing it for 16+ years with help from others.
• 22 March 2020: You can get a framework around it in Part One of Shape Up. http://basecamp.com/shapeup The formalism and notation for positive/negative shaping is new.
• 22 March 2020: This is all new stuff.
• 22 March 2020: See how quickly new major elements enter the system because of the lightweight notation. The systems that make up "home" are getting populated. If necessary it's very easy to move them around or factor them out to some other place. pic.twitter.com/vTk97iiA9l
• 22 March 2020: The idea of making a function the unknown and surrounding it with knowns to figure out what it should be is very powerful. That's the core idea of negative shape.
• 22 March 2020: Negative shape defines a hole to fill. The hole still has a shape. But it leaves a lot of details missing. Positive shape fleshes it out.
• 22 March 2020: I haven't explained these terms anywhere yet except loosely in some tweets. Negative shape is when you define the boundary. Positive shape is when you define the interior.
• 22 March 2020: This bottom-up approach to design is more than 16 years in the making (with longer history in Christopher Alexander's work). Here's a post showing a very early version from back in 2004: https://37signals.com/papers/introtopatterns/
• 22 March 2020: In the fast-moving creative phase, identifiers ("S1, S6" etc) are easier to quickly type and move than full descriptors. Better to name things after you've settled what they are, what they do, and how they combine. Label everything later when presenting to others. pic.twitter.com/Sh82Q22paj
• 22 March 2020: Thanks but it's not meant to be generally applicable. A different site with a different purpose could (should) have an entirely different design.
• 22 March 2020: An early look at what shaping looks like one level of abstraction up from breadboarding. https://twitter.com/rjs/status/1241816956140810240?s=20
• 22 March 2020: Note the simultaneous abstraction and specificity. On the negative side, each piece is a function — it does or accomplishes something. The structure is functional, not categorical.
• 22 March 2020: This is very different from wireframing. Shaping a proposal to redesign a website. Starting with negative shape — what it has to do. Identifying problems. Then assembling the pieces into a positive shape. pic.twitter.com/a6PGsFjIHj
• 22 March 2020: Yes.
• 22 March 2020: When people say "we need help with our UX" — start by observing two different kinds of UX: domain-specific and universal. Universals are things like labeling confusing icons. Domain-specific is getting unconfused about what the thing is actually supposed to do and fixing that.
• 22 March 2020: TDD (test-driven development) is another instance of this general approach. But limited to the supply side.
• 22 March 2020: Seeing now that the key idea from Products Are Functions is actually the concept of negative shape. Defining the space that something fits into before defining the thing. Then using that as constraints for possible solutions. http://www.feltpresence.com/functions.html
• 22 March 2020: You evaluate by putting them together and looking for misfits and problems. Eg the site presents info behind a link. People come for that info, but have different terminology in mind and don't see the link. Now the misfit defines a new negative space for a new positive solution.
• 22 March 2020: The positive aspect is the actual form of the thing. The design with the button here and the text there. The negative aspect is the space to fill defined by the situation where the thing is supposed to do something.
• 22 March 2020: The same applies to any internal work. You can't critique something unless you first clarify what it's supposed to do. Then you have the positive and negative aspects of the shape to test against each other for fit.
• 22 March 2020: Whenever people ask me if I can give feedback on their site/product, my first answer is: no. Why? Because I have to learn about the problem before I can evaluate the fitness of the solution. If time allows, that's the next step. THEN feedback.
• 21 March 2020: Extremely clear and well-reasoned op-ed by @yaneerbaryam — a pandemics expert — arguing for a five-week national lockdown. https://www.usatoday.com/story/opinion/2020/03/21/coronavirus-america-needs-five-week-national-lockdown-column/2890376001/
• 21 March 2020: This is all very early. Just starting to formalize this.
• 21 March 2020: I think the tools we need for that are conceptual tools. Like the ability to flip perspective from supply side to demand side (in Alexander's language, form to context), negatively shape constraints from the demand side, positively shape the supply again, and evaluate for fit.
• 20 March 2020: Interesting connection between typology of form and stability from Léon Krier here (via @wrathofgnon ) That is, if the form of a thing keeps substantially changing, it means we haven't understood something fundamental about the design. pic.twitter.com/upznuJSrQr
• 20 March 2020: Innovation in response to a struggling moment. https://twitter.com/yaneerbaryam/status/1240832025155813382?s=20
• 19 March 2020: Yes. The f(x) is user-scale but the x isn't.
• 19 March 2020: Not a direct competitor.
• 19 March 2020: I use a variety of things for different circumstances. - Sketching/thinking: Notability or Whiteboard + camera - Capturing from / prepping for a call: TextEdit - Capturing knowledge from in-progress work to pick up later: Roam - All else: Apple Notes (phone or desktop, iCloud)
• 19 March 2020: Very fresh and inspiring UI here on LiquidText. https://youtu.be/nTHfjt9rgWQ
• 18 March 2020: Mass feedback is appropriate for things that are already shaped, built, and nearly ready to ship. Eg a draft of a paper that's ready to go but might have typos or errors. That's very different from getting mass feedback on the concept.
• 18 March 2020: Gather feedback from wider groups by taking the in-progress idea through multiple tiny closed-door sessions with different people. Don't put them all in one room at one time.
• 18 March 2020: Yes! Small, closed-door sessions for ideas that aren't fully shaped. https://twitter.com/ThatDetroitAndy/status/1240333297273708546?s=20
• 17 March 2020: I think it’s a distraction from executing the basics and getting the needed reality check from the market.
• 16 March 2020: Thank you. Been calling this “breadboarding” more recently. The latest version is here: https://basecamp.com/shapeup/1.3-chapter-04#breadboarding
• 13 March 2020: Surprised to see a connection between what you’re doing and stuff I’ve shared. So cool. Please reach out if you think I can ever be of help on something you’re struggling with.
• 13 March 2020: Cool to hear. It’s such a fascinating challenge when doing product design/development to repeatedly make 180° heading change from “toward new functionality” to “toward closure around what we’ve demonstrated to be valuable” and back.
• 13 March 2020: The opportunity (my guess) is to execute the basics more and address the low end of the market. That means solving elementary interaction problems (eg with inserting images/files) and accessibility across space (diff platforms) and time (robustness to uptime/network issues).
• 13 March 2020: Really liking @RoamResearch but worried about their strategy. They appear to be gazing upmarket (at advanced productivity / methodology tricks) when the gold they’ve struck is a new mix of very basic elements.
• 13 March 2020: My favorite explanation is in Notes on the Synthesis of Form, Chapter 2: “Goodness of Fit”
• 12 March 2020: More isn’t better. Less isn’t better. Fit is better.
• 12 March 2020: Happy with Notability. It’s constrained in just the right ways to give me faster access than Concepts for the things I do most often. Concepts feels like it’s giving me way too many options too many taps away.
• 12 March 2020: Thinking about how @KentBeck wrote Smalltalk Best Practice Patterns — he went meta at every step of real work and asked “What did I just do? Have I done this before?” Trying the same on some shaping work. Not just sketching, but annotating each false step and corrective measure. pic.twitter.com/SYcZ3ZNtzT
• 12 March 2020: https://basecamp.com/shapeup/2.2-chapter-08#team-and-project-sizes
• 12 March 2020: In the summers we ship ~ every 9 weeks (4-day work weeks, 8-week cycles, 1-week cool-downs).
• 12 March 2020: We ship meaningful improvements ~ every 8 weeks (6 week cycles, 2 week cool-downs between). Lately teams have been focused on HEY, a new product ( http://hey.com ), and shipping new features to an internal-only beta every cycle.
• 12 March 2020: That’s a great example of how looking at it from the perspective of a different pathway leads to very different design ideas.
• 12 March 2020: Eg in Basecamp, we see some people come in and they know exactly what the work is that needs to be tracked and everything starts from there. Other people don't know what the work is, but they know who does know, so they give those people a space to define the tasks.
• 12 March 2020: The path depends on the context. There's enough overlap in context that there don't need to be infinitely different paths... 3-5 different ones could be enough for a given domain. Needs to be determined empirically, not a priori.
• 12 March 2020: This new podcast from @stevenstrogatz is fantastic. For curious people who like unsolved problems and applied science and math. More about wonderment and the mysteries of the real world than scientism. https://www.quantamagazine.org/tag/the-joy-of-x
• 12 March 2020: See 'The End of Average' for a good, short, to-the-point discussion of "pathways" and how different pathways work better for different people. https://www.amazon.com/dp/B00R1JU7P6/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1
• 12 March 2020: Why @RoamResearch 's Daily Notes feature is interesting: https://twitter.com/rjs/status/1237914903500820480?s=20
• 12 March 2020: Yes. A pure graph doesn't have a beginning, end, or direction. A timeline that points to the graph gives you a canonical path through it and a way to backtrack.
• 12 March 2020: Action under acceleration.
• 12 March 2020: Example: I noted some meta-work I did today on 'negative and positive' shaping. I didn't know where that belonged, so I just noted it as a kind of journal entry for today. Then decided to link it to page and, on that page, fleshed out a quick sketch of the observation. pic.twitter.com/4eAhmCsgZ2
• 12 March 2020: A very interesting feature of @RoamResearch : Daily Notes. At a minimum, there's always a place for a note: today's page. And since any pages you create from that point don't live "under" the original page, there's no harm in starting things there.
• 12 March 2020: It's another case where the competitive set doesn't trace the lines of a supply-side product category like "notes apps" or "information organizers" etc. Example: @RoamResearch competes with leaving browser tabs open.
• 12 March 2020: I'm happy to lean on Apple Notes / iCloud for capturing random little things. @RoamResearch is appealing for things that are closer to little projects. When I've just built up some knowledge about something that I'm going to want to continue working on later.
• 12 March 2020: Yeah. Lack of mobile is a concern for me too. But anyway interested to give it a shake and see what it teaches about the state of the art of tools in this domain.
• 12 March 2020: Wikis have always been good for sharing, but not for capturing. Tools that are good at capturing require fewer structural decisions up front and have fewer penalties for putting something in the wrong place. More "liquidity." This is a basic trade-off in information tools.
• 12 March 2020: Small changes can make a big difference. Test driving @RoamResearch . It's just different enough from a traditional wiki to do a different job. Everything is a bullet and links are bidirectional. Means there are fewer structural decisions to make, so it's easier to dump info in.
• 11 March 2020: @RoamResearch Trying the app for the first time right now. I find myself adding blank lines with a bullet like below to separate sections so the page isn't crammed and I can more easily scan it. Is there a better way to create dividers or section breaks that I'm missing? pic.twitter.com/BPzT168SYa
• 11 March 2020: Variable scope isn't about quantity. It's about making choices as you go — choosing what's in and what's out. With fixed scope you don't make choices, you just do it all.
• 11 March 2020: Glad to help. And happy to see the new podcast — it’s excellent.
• 10 March 2020: Notability + Zoom on an iPad. Connect to a meeting using Zoom. Then use the screenshare feature to share your Notability app. You'll be able to draw, continuously scroll, and draw more as you lecture and they'll see everything.
• 10 March 2020: You can also interview people who bought something that you view as a competitor to the thing that you haven't built yet.
• 10 March 2020: In the case of a new product, new scenario... here's an example. I couldn't interview people about the book Shape Up before I wrote it. So I offered a workshop and then interviewed people who paid for the workshop. Details here: https://m.signalvnoise.com/how-i-wrote-shape-up/
• 10 March 2020: There's an extremely important skin in the game principle here: We only interview people who shopped and bought something. Then we can learn all of the causality around the decision.
• 10 March 2020: It's easier to see the edges between clusters using Ward's method. K-means blurs them more around the centers. We'd need someone with more expertise to better explain why.
• 10 March 2020: Yeah it's all design.
• 10 March 2020: This is the basic idea of “spiking.” You can think of a spike as a graph over time, where the y axis is concreteness.
• 10 March 2020: Having proven a concept is viable with a quick wireframe or even higher fidelity mock, you can step back again to the higher abstraction version. That leaves the space of possibilities open for another designer or programmer to come up with a better approach to the specifics.
• 10 March 2020: To stay grounded, alternation is a useful tactic. After sketching out the idea at a higher level of abstraction (language, affordances, connections...) try a quick wireframe to see if you can instantiate it down a level of concreteness. That proves you aren’t in the clouds.
• 10 March 2020: Yeah @claychristensen used that same term (“interdependent”) for the third category. To my ear, dependent vs interdependent is too subtle so I’m staying open to different ways of framing it.
• 10 March 2020: Yeah. Early agile was full of good ideas (I learned a lot from it). At the same time, it was confined to engineering teams and didn’t say much about how design, engineering and biz integrate. It was more about “programmer vs. customer” than product.
• 10 March 2020: Wireframes are too concrete for the earliest, first stages of a design. More important to start with language and interdependencies. There could be dozens of visual solutions. But if the concepts don’t make sense, it’ll be wasted time. pic.twitter.com/tluIl5f8S7
• 10 March 2020: Not so black and white. There is fully independent, partially independent via declaring an interface, and fully dependent because they must be solved together as a bundle.
• 10 March 2020: (See https://basecamp.com/shapeup/3.3-chapter-11 )
• 10 March 2020: This maps to what we call “scoping” in the middle of even a single project (building A). We want pieces to be “done” in the sense that they independently do something at user-scale instead of designing a bunch of threads that are supposed to weave together in the 11th hour.
• 10 March 2020: Contrast to what many software teams do. They build 2.a all the time. And value is always in the future, when some other thing gets built that finally ties it all together.
• 10 March 2020: We always prefer 2.b when possible. That allows us to bet time on A, get value from A, and if B never comes, we still accomplished something.
• 10 March 2020: (Sorry, this is abstract, but I can’t share the project I’m working on yet...) In Type 2, distinguish between two kinds of “done”: 2.a: “Done,” but doesn’t deliver value by itself. Depends on B to be useful. 2.b: “Done,” delivers value by itself, and B will deliver diff value.
• 10 March 2020: Type 1 also matters because we too easily bundle things together we think we “have to have” because we haven’t challenged ourselves enough to factor / decouple / decompose.
• 10 March 2020: Not going to move/change, a commitment in the basic design of what you’re doing.
• 10 March 2020: Type 1 is the simplest cut. Say I’m trying to untangle A from B. “I don’t have to care about B right now. It doesn’t affect A.” Type 2 requires designing A to accommodate B later, but in such a way that A can be “done” first.
• 9 March 2020: Shaping a project right now and doing some untangling to hammer the scope. Seeing two kinds of orthogonality: Type 1: I don’t even have to think about that other thing. Type 2: I‘ll need that other thing, but I can design a hard interface to it to stop thinking about it now.
• 9 March 2020: That doesn’t mean that all ideas come from JF and me. It’s a question of doing the work to take something from a raw idea/suggestion to an actionable shaped project.
• 9 March 2020: We have a small team with four of us for reviewing pitches and making bets.
• 9 March 2020: We encourage anyone in the company to share ideas. At the same time, we’ve learned that shaping a pitch requires dedicated time and acquired skill. So in practice JF and I are responsible for most shaping.
• 9 March 2020: Thanks. It's built in Jekyll. @adamstd designed and implemented it. Self-hosted.
• 9 March 2020: Site diagnosis: “This is the opposite of a master plan approach. A master plan tells us what is right for the future. Diagnosis tells us what is wrong in the present.” https://www.garethrees.co.uk/2020/03/08/book-notes-the-oregon-experiment/
• 8 March 2020: Excellent.
• 6 March 2020: No
• 6 March 2020: See thread starting here: https://twitter.com/MyGuySi/status/1235445836546543621?s=20
• 6 March 2020: Yes, forum here: http://discourse.learnshapeup.com First remote meetup March 25th: https://discourse.learnshapeup.com/t/shape-up-practitioners-remote-meetup/225/4
• 6 March 2020: I know that very well. The business literacy enables people to understand what’s happening, including in situations where they have no power to change it. It’s better than wondering “why are we struggling so much?”
• 5 March 2020: And the more you can avoid running your nose into the wall because your expectations don't match the reality you're in.
• 5 March 2020: Clay Christensen was famous for "disruption." His deeper contribution, and the one more applicable to all of us, was an axiom: whatever happens should be explainable with cause and effect. Through causality we can make more sense out of the world around us, business and life.
• 5 March 2020: The question is whether you understand your situation or not. Whether you can influence it is something else. Seeing it and knowing what's happening means you'll be less surprised and caught off guard and better able to make judgements when opportunities do arise.
• 5 March 2020: Also look at how Clay analyzes other businesses and industries. I'm not in healthcare and I'm not even a business person but The Innovator's Prescription gave me lots of language and examples to frame problems I was seeing around me. https://www.amazon.com/Innovators-Prescription-Disruptive-Solution-Health-ebook/dp/B001FA0NS8/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=1583446485&sr=1-1
• 5 March 2020: For me, The Innovator's Solution was very educational. https://www.amazon.com/Innovators-Solution-Creating-Sustaining-Successful-ebook/dp/B00E257S7C
• 5 March 2020: If you want an armchair business education to help you tease all this apart, I highly recommend spending time with Clay Christensen's books. Forget about disruption. Learn about resources/processes/priorities, good and bad money, modularity and interdependence, jobs to be done.
• 5 March 2020: Ask yourself: Where is the money coming from? Why are these the goals that I'm supposed to pursue? Are the goals that I'm being given align with the strategy that I thought I was supposed to be pursuing?
• 5 March 2020: In this case the business has split into two businesses: a solution shop that's doing custom work for clients and a product business that never gets resources. Seeing this clarifies so many daily struggles, but one has to look up to see it.
• 5 March 2020: Common case: A company that is supposedly building a platform spends all its resources doing special jobs for big paying customers. They have high growth targets from VCs but none of their investments will produce growth because they're just consulting for their clients.
• 5 March 2020: Talking to CTOs and product leaders trying to implement Shape Up makes something clear: Individuals need more business literacy to debug what is going on above them and why they struggle so much.
• 5 March 2020: Mostly daily work of most people in the industry is not creating a Facebook or Twitter.
• 5 March 2020: See also: An 'undesigned' serif in the pgLang identity: pic.twitter.com/TBOkoaLanZ
• 5 March 2020: The thing that puts fashion way out on the far edge of design is how it resolves a field of forces in today's context that is so hard to define it can't be articulated as a problem statement. 180° from the analytically-driven stuff we do in software design. From Yeezy Season 8: pic.twitter.com/3dQmgXpMH2
• 5 March 2020: Yeah that’s a good deep one related to unfolding.
• 5 March 2020: This framing of a design as form, context, and fit highlights how the the designer defines not only the solution but also the problem. It's a duality. "Forces" then are aspects of the context given a form/context pair that the designer treats as constraints on the form.
• 5 March 2020: Forces are "resolved" if they don't come into conflict. Example of a conflict: to stay in budget you make the kitchen smaller, but you cook dinner parties and there's not enough space for extensive meal prep. You make a different tradeoff to save $ elsewhere and regain the space.
• 5 March 2020: Alexander divides a design problem into form, the thing you're making, and context, the world and situation it belongs in. The goal is good fit between those. "Forces" are aspects of the context that bear on the form. As an ideal, imagine iron filings ordered by a magnetic field.
• 5 March 2020: See chapter 2 of Notes on the Synthesis of Form. Maybe I'll give a short explanation in the primer. Not sure yet what that's turning into.
• 5 March 2020: All of these are in Shape Up of course but this is about presenting them in their original context and sources.
• 5 March 2020: First outline for a primer on important ideas from Christopher Alexander’s work that apply to product design and development: https://twitter.com/rjs/status/1235329778737176581?s=20
• 5 March 2020: From the forum: “Is it ok to move things backward on the hill chart?” https://discourse.learnshapeup.com/t/explaining-the-hillcharts/145/10
• 4 March 2020: Thank you. The online book was built and designed by @AdamStddrd in Jekyll with custom code and templates.
• 4 March 2020: @normonics Would you add anything to this very high level summary of Alexander's work?
• 4 March 2020: No one has written a good summary/overview of his work yet and his insights are scattered across many books. I keep telling myself I'll write a primer. Just sketched an outline: pic.twitter.com/707Wwv2rpv
• 4 March 2020: Not scheduled yet. We'll likely do some things later this year. Speaking at some conferences in the spring (details still coming together).
• 4 March 2020: Shape Up practitioners: @davidarens is organizing a remote meetup on March 25th "where we can talk, learn, help each other out and get to know others who are trying Shape Up." Details: https://discourse.learnshapeup.com/t/shape-up-practitioners-remote-meetup/225
• 4 March 2020: @AdamStddrd set up the Jekyll site and knows about that.
• 4 March 2020: I’ve been hearing this about Shape Up more often than I expected from data science folks. https://twitter.com/EmilyRiederer/status/1235023766696022016?s=20
• 4 March 2020: That’s cool to hear. I’ve been in touch with a few data scientists and they all told me Shape Up has been a good fit for how they define and tackle projects.
• 4 March 2020: https://basecamp.com/shapeup/1.3-chapter-04#breadboarding
• 4 March 2020: Probably zero demand for this, but I’ve been looking for a connection between Cognitive Grammar and design for 10+ years and finally found it recently. A design element maps to Langacker’s symbol. Its form corresponds to the semantic pole. Its name to the phonological pole. https://twitter.com/rjs/status/1234989817848446978
• 3 March 2020: Thus the famous adage: “there are two hard problems in computer science: cache invalidation and naming things.” ( https://martinfowler.com/bliki/TwoHardThings.html )
• 3 March 2020: A beautiful thing about creating new things is the form precedes the name. You can make something — a method in code, a piece of UI, a new hardware element — and it does something before you know what to call it. Naming it enables you to then describe larger wholes it belongs to.
• 3 March 2020: Design being a language, we can borrow some terms from Langacker. A name-form pair with “unit status” is one you can invoke as a whole, conventionally. Eg “text field” or “menu bar.” Unit status is relative to some community. Eg at Basecamp we have “permas” and “commentables.”
• 3 March 2020: This ties to Alexander’s idea of a design as a language. A realized design has both ‘name’ and ‘form’. Here we don’t know the names of each step yet and just a little about the form of each step. For a novel element, the form comes first and the name later.
• 3 March 2020: Each empty box represents the earliest outline of a step in a process that needs to happen to accomplish something the user is trying to do. Compare to starting w/ a wireframe. It’s all about movement, dynamics, process, change. Not about spatial arrangements or visual elements. pic.twitter.com/Xv7v1gED1E
• 3 March 2020: The empty box is a function. This approach gradually shapes the design by defining the dynamics first, not the static elements. The verbs, not the nouns. Eg instead of designing a beverage container w/ a “cap,” start with a function: “seal.” Cap is a solution, not a requirement.
• 3 March 2020: The empty space in the box eventually gets filled with a breadboard or fat marker sketches that fulfill the actions so the inputs produce the outputs.
• 3 March 2020: Working toward a design from the outside in using system mapping — a technique from @bmoesta with lots of overlap w/ Christopher Alexander’s bottom-up pattern language approach. This phase is even earlier and more abstract than breadboarding. pic.twitter.com/LOosNxw3X7
• 3 March 2020: Both words assume motivation to do something.
• 3 March 2020: This gets at the causal structure around the word in question. What does it enable them to do or not do? How do you cause it to happen or stop it from happening? What’s the opposite and how do you know what is enough or too much?
• 3 March 2020: I find it helpful to view it as intense interest and curiosity in their world and their experience. This, when it’s true, can be felt by everyone and it’s a nice feeling not a discomfort.
• 3 March 2020: I also like “enable.” And of course our key word as designers — “affordance” — also describes the relationship.
• 3 March 2020: Another technique is bracketing: set aside what you know about something and ask them to fill in the meaning. “You said it’s ‘slow.’ What is ‘slow’?” Or “Why is slow bad? What’s wrong with slow?”
• 3 March 2020: Yeah I think one has to learn by exposure to good examples. Not many out there yet but maybe this can change.
• 3 March 2020: There's might be some interesting work to be done here to connect these forward/backward flows with Kauffman's work-constraint cycles. Shaping constraints, then working within those constraints, then modifying the constraints, etc.
• 3 March 2020: Good point. Better to frame both as activities than people/roles/types.
• 3 March 2020: Yes agree. The name is secondary.
• 3 March 2020: The designer's fundamental question: how do I cause that particular thing? We work backwards from ends. The artist's fundamental question: how do I express that particular thing? They work forwards from experiences.
• 3 March 2020: @nntaleb 's work on politics at different scales is a good example. The differences are more important than the similarities.
• 3 March 2020: To my ear fractal emphasizes similarity across multiple scales. Versus multi-scale can just as well point to differences. The fact that structure at different scales calls for different framing and action is important.
• 3 March 2020: And everything in Alexander's work and process is about dynamics: what happens through time. It's based on the unfolding of relationships, not imagery. Imagery (eg "Bauhaus") is spatial, not temporal. Has no cause-effect structure.
• 3 March 2020: @normonics @meedabyte @JoshHochschild @agostino_harry @nntaleb Some deep things about Alexander: He deeply understands different levels of abstraction at different phases of design. And the relationship between name and form. Sometimes we can describe what we want but it doesn't have a shape yet. Or we have a shape but no name for it yet.
• 3 March 2020: Yes. Christopher Alexander teaches mostly through case studies. His books give a chance to see lots of examples of how order can be unfolded rather than dictated. In addition to Book 2, highly recommend "Battle" for an in-depth end-to-end case study of a single project.
• 3 March 2020: Yes. The questions are about the causality of the story, not about the product. The story is about: • discovering something isn't right • looking for alternatives • eliminating options • getting pushed to decide by the running out of time, knowledge, money, or energy
• 3 March 2020: Nassim Taleb is self-publishing his new technical book. https://twitter.com/nntaleb/status/1234439613642682373?s=20
• 2 March 2020: "My goal has never been to be right but to find the right answer. They’re very different things." - @claychristensen https://sloanreview.mit.edu/article/an-interview-with-clayton-m-christensen/amp
• 2 March 2020: I'm just stealing from you.
• 2 March 2020: Yeah. First we need a casual picture with a failure in it. Then what "we need" is a design problem to fill the space of the failure. The shape of the failure creates the borders of the design requirements.
• 2 March 2020: Non-consumption is when supply doesn't meet the demand. We can find it by following the causal dynamics of the demand and observing where and when they die out.
• 2 March 2020: Supply and demand is a dynamic system. Due to certain causes, someone makes a judgement that what they already have or do isn't working. Then they perform actions to change the situation. The demand is the causality behind the search; the supply is the space of the search.
• 2 March 2020: Cause and effect is impersonal and doesn't discriminate. When /these/ conditions come together, /that/ happens. Whether it's what makes us reach for a Snickers or start searching for software, we understand it best when we look at sequences of events instead of personalities.
• 2 March 2020: The purpose of interviewing customers isn't to find out what they want or what they think. It's to find out how things work. What leads to what as cause and effect. Then we can see where things break down, what's missing, and where opportunities lie. https://twitter.com/rjs/status/1234617860141408256?s=20
• 2 March 2020: New post: "Keep digging" — on customer interview technique. "Sounds like a clear answer, right? No, not yet. That answer doesn’t tell us anything about what to do." https://m.signalvnoise.com/keep-digging/
• 2 March 2020: Thanks. Here's the latest version of that shorthand: https://basecamp.com/shapeup/1.3-chapter-04#breadboarding See also: https://discourse.learnshapeup.com/t/breadboarding-simplify-with-partials/98
• 27 February 2020: The Shape Up landing page got a design refresh thanks to @AdamStddrd . Now updated with testimonials from successful early adopters and a link to the new discussion forum. https://basecamp.com/shapeup
• 27 February 2020: Many fields have two centers of gravity: where the money/media are, and where the truth is. Seen from historical time scale, they sometimes cross paths in brief and exciting flashes. For economics, the center of gravity for truth is with EE and it’s starting to gain attention. https://twitter.com/ole_b_peters/status/1233055886639271940
• 27 February 2020: Chris is basically the first Shape Up adopter outside of Basecamp. Really exciting to see the results here.
• 27 February 2020: Fantastic behind-the-scenes case study on how @chriscbs and the Autobooks team did customer interviews, shaped a feature idea, said “no” again and again, and built it in four weeks. https://overcast.fm/+X31DxWet8
• 27 February 2020: Moscow is of course much bigger than Chicago, and more international style. Those I met through my friends were very open-hearted and full of feeling.
• 27 February 2020: Most interesting systems have dynamics at more than one scale. So our designed responses should also be multiscale. Here Chen Shen and @yaneerbaryam give advice on managing coronavirus at individual, local, and state scales. https://twitter.com/yaneerbaryam/status/1232407061046218752
• 26 February 2020: Back from a 4+ week long tour across Russia with friends, from Moscow to Vladivostok. Full of amazing impressions. At one point, only 560m across the Amur river from China, I was especially glad to have @yaneerbaryam ’s coronavirus updates. https://twitter.com/yaneerbaryam/status/1232755578788892672?s=21 https://twitter.com/yaneerbaryam/status/1232755578788892672
• 3 February 2020: We don’t have any tickets in our six week cycles, so it’s a very different dynamic.
• 17 January 2020: The classic reference is JJ Gibson: https://www.amazon.com/Ecological-Approach-Visual-Perception-Psychology-ebook-dp-B00PWAKE2M/dp/B00PWAKE2M/ref=mt_kindle?_encoding=UTF8&me=&qid=
• 17 January 2020: Rare opportunity to work on the Research & Fidelity team with @sstephenson and @javan at Basecamp: https://apply.workable.com/basecamp/j/F2CB808F33/
• 17 January 2020: "Loss aversion" is not a real thing. https://twitter.com/ole_b_peters/status/1218171528438853632?s=20
• 17 January 2020: Yeah also depends on the stakes. This is a project that I think is strategically important for us. I want to do whatever I can to prevent the project from getting tainted by a blow up or some question that I can't answer.
• 16 January 2020: I bet it’s possible to design an introductory course on Design around the concept of an affordance. So much unpacks from there. https://twitter.com/rjs/status/1217947689473601536
• 16 January 2020: No plans for Markdown support right now. Anything is possible in the future but we’re unlikely to go down that specific path.
• 16 January 2020: Eg you can use a button to test if your computer is frozen or not by clicking on it. It affords lots of things. But if I design it for one specific purpose (submitting a form), I can think of it as an affordance for that one thing.
• 16 January 2020: Technically yes, an affordance is a property of an object perceived by a subject dependent on their purpose. Eg the hill affords climbing or rolling down. In practice as designers we take a specific stance as subject and design objects to afford things. So we flatten the term.
• 16 January 2020: Saliency is circumstantial. Not only do we not value things until we need them ... we don’t even see them until they have some use to us.
• 16 January 2020: To figure out how people “value” a product or feature, we have to look at the supply x demand integration: In what situation did the demand arise? Due to the demand, which affordances became salient? Having become salient, how did they apply the affordances to do something?
• 16 January 2020: That’s why the “job” isn’t something a product does by itself. It’s something the product can do for someone who is in a specific situation on the demand-side. The concept of affordance captures this incompleteness. It’s only half of the story.
• 16 January 2020: A “job to be done” is a special case of an affordance. The supply affords doing something in a certain situation. That’s a job. The ability to do something (the value) is an integration between the supply side and the demand side. You can’t use a hammer without a hand.
• 16 January 2020: Affordances are multi-scale. A method in code is an affordance. The button that calls it is an affordance. The entire product is an affordance. An affordance is a piece of supply that, when integrated by the one with demand, gives them a new ability.
• 16 January 2020: A few hours of spiking removed tons of uncertainty on a potential six week project. Way better to risk the three hours to find a potential hole than to risk the whole six weeks with fingers crossed.
• 16 January 2020: (Context: https://basecamp.com/shapeup/1.4-chapter-05 )
• 16 January 2020: For #2, the question isn’t “what’s the right solution.” The team will figure that out. The question is, of the potential paths we can see, do they terminate or if we pull the string do we keep finding more problems and complications. If the former, it’s safe to move on.
• 16 January 2020: In a deep “de-risking” session on a shape w/ a tech expert. He built a spike. Answered two kinds of questions: 1. Are the “straight shots” where we expected them to be? 2. For trickier things with multiple implementation paths, do the paths terminate or are they rabbit holes?
• 16 January 2020: All those decisions reflect trade-offs we've made so far. Some people don't like those trade-offs, so they choose a different product. Many others are thrilled with Basecamp. We do consider all the feedback that comes in. Thanks for taking the time to spell your thoughts out.
• 16 January 2020: https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs
• 16 January 2020: Gotcha. Yeah if you do need some significant refactoring to move forward, I would shape that and treat it as part of the work to implement the new thing. Best time to pay it down is in pursuit of something you want.
• 16 January 2020: @LaissezWhere @dhh There’s a chicken-egg thing here. The more rushed projects are and the less thought-out the architecture is, the more you’ll want to repeatedly break up concrete when you pursue new things. And vice versa.
• 16 January 2020: We’re big believers in refactoring on the way to get something new, not just refactoring to refactor. I don’t think we’ve ever had an 80/20 cases where the majority was refactoring. @dhh often uses the phrase “breaking up concrete” for huge refactorings. We avoid those.
• 16 January 2020: * load bearing
• 16 January 2020: That’s part of the shape. You should know about the big load Bering technical pieces before making the bet. (I’m assuming familiarity with Shape Up here.)
• 16 January 2020: You look. Do some light spiking before making the bet. It’s not a black hole or a hidden mystery. Look at the existing code, see how it works, tug on strings, and see where your new thing has to connect. No 100% certainty, but you can get a good idea.
• 16 January 2020: 2. We don’t accumulate tech debt Building from scratch every few years doesn’t save us at all from tech debt. The reason we don’t have tech debt and a lot of necessary refactoring is we end every cycle with only clean code that we’re proud of.
• 16 January 2020: No. Two things. 1. Necessary refactoring != unnecessary abstraction If we had a lot of tech debt, that would make features take longer to build because it would get harder and harder to add new things. That would be a different category than “unnecessary abstraction.” ...
• 16 January 2020: Good reference. Thanks.
• 15 January 2020: Re “you never know” the capacity to reserve (padding) depends on the type of error distribution, thin vs. fat-tailed. Per @nntaleb ’s work, a fat-tailed process can masquerade as thin-tailed with too few observations... except when you can inspect the generating process.
• 15 January 2020: Reserving capacity makes sense when you can’t see the process generating your error. Eg building flood walls 2x height of last flood because “you never know.” But when shaping dev work, you can inspect the process. You can look at the existing code, spike experiments, etc.
• 15 January 2020: Also this: https://twitter.com/rjs/status/1217592096812494848?s=21 https://twitter.com/rjs/status/1217592096812494848
• 15 January 2020: An unappreciated source of scope creep: under-the-hood implementation scope. That’s additional work to do what was already shaped because the team pursued a complex implementation or an unnecessary abstraction. Tons of scope creep comes from inside the build team, not outside.
• 15 January 2020: Yes. But a lot of scope creep comes from doing things that aren’t worth it: - Adding functionality for consistency/symmetry w/o questioning if it will be used - Undertaking an expensive abstraction out of principle “it must be DRY” - UI innovation the customer doesn’t value
• 15 January 2020: Agree. We may get there eventually. Answer to “why not” is opportunity cost. It’s not the only thing we want to do. Have to judge what is more valuable at a given time.
• 15 January 2020: Padding leads to infinite regress. There’s always more. Hammering pushes back on the scope because there’s a time wall — a hard limit. Limits means trade-offs. Trade-offs mean saying “no” to some things. Saying “no” means shrinking the scope back to manageable size.
• 15 January 2020: Two different approaches to scope creep: - Hammering: We take responsibility to make trade-offs, say “no,” address new issues with tough design decisions. - Padding: We assume any new scope that appears is inevitable, uncontrollable, must-be-done; add extra time to cover it.
• 15 January 2020: The concepts are most important. I use them on solo projects as well.
• 14 January 2020: Yes they are in the same branch. They frequently communicate with each other about what piece they are working on and don’t work on the exact same area at the same time, so merge conflicts are rare.
• 10 January 2020: We’ll be most interested in #2 when we learn about a pain point that (a) can cause a meaningful number of people to switch to or from Basecamp, (b) fits coherently with the main jobs our customers hire BC to do, and (c) that we want to build.
• 10 January 2020: Information architecture is a broad umbrella. Breadboarding is a specific technique. In my experience IA is usually associated with web site development rather than app development. Breadboarding is specifically about app interfaces and flows.
• 10 January 2020: Yeah arbitrary client demands fall into the “fiat” category.
• 10 January 2020: Thanks.
• 10 January 2020: We can not know, not be perfect, not have the right answer up front ... and still do things. That's the domain of the risk taker. It's also why founders can be so temperamentally different than employees and how inaction and paralysis can set in as companies grow.
• 10 January 2020: Epistemology is undertaught and undervalued. It's such an important skill to inwardly separate speculation from knowledge. To ask: do I know that and how? We can still act on our speculations. But consciously, not blurring what we hope or fear with what we really know.
• 10 January 2020: Very often, #1 doesn't have clear problem definition. It's an "I want to do it because I want to try it" kind of thing.
• 10 January 2020: Eg. #1: "I had this cool idea for a new take on the client landing page today." #2: "Customers aren't using that client toggle the way we expected. Here's what we're hearing." #3: "Ugh I hate when I have to mark a Ping unread to remember something. What if we did this..."
• 10 January 2020: #1 is speculative ("let's try X", "it would be cool if...") vs #3 is grounded in a real felt itch or pain point. Different worlds in terms of confidence and clarity around the problem.
• 10 January 2020: You can also be sure there is a problem with research (certain behaviors make it clear people are struggling). The challenge is figuring out what exactly the problem is, what the context for it is, and gaining confidence that you understand it well enough to solve it.
• 10 January 2020: Said more simply, they are in different worlds in terms of confidence in the problem.
• 10 January 2020: It’s very different because feeling an itch directly is different from triangulating a problem through research. They are in different worlds epistemologically.
• 10 January 2020: After a product is out and starts to mature, feature development is driven by a mix of 1, 2, and 3.
• 10 January 2020: Out of the three types of strategic direction, Basecamp always builds new products with #3. 1. By fiat — an owner just wants to build it. 2. By research — we learned customers want it. 3. By scratching our own itch — we want it for ourselves. https://discourse.learnshapeup.com/t/what-about-strategy/34/3?u=rjs
• 10 January 2020: “Q: What about strategy?” This could be a whole book after Shape Up. Here’s an outline. Featuring: demand-side vs. supply-side work. Strategy as a filter. The differences between strategy by fiat, by research, and by scratching your own itch. Plus more. https://discourse.learnshapeup.com/t/what-about-strategy/34/3?u=rjs
• 9 January 2020: Smalltalk Best Practice Patterns by @KentBeck is #lindy . Written in 1996. Still relevant. https://twitter.com/rjs/status/1215418263456206848?s=21
• 9 January 2020: A connection between breadboarding and good programming practice: https://discourse.learnshapeup.com/t/breadboarding-how-to-use-partials/98 pic.twitter.com/iRKifLExyu
• 9 January 2020: New on the forum: How to use a technique borrowed from Ruby on Rails templates to simplify your breadboards https://discourse.learnshapeup.com/t/breadboarding-how-to-use-partials/98
• 9 January 2020: The Shape Up Forum is now online. Ask questions and learn what other early adopters are doing. Here's the first post, a collection of before/after experiences: https://discourse.learnshapeup.com/t/experience-reports-before-and-after-shape-up/16
• 7 January 2020: We don’t have roadmaps per se but we’ll have themes at a high level that inform what we choose to work on. I like to think of whatever happens at the scale above cycles as a filtering mechanism. @chriscbs and I talked about this here: https://demandthinking.com/episodes/2019/11/18/episode-4-metrics-arent-projects
• 4 January 2020: New podcast interview about Shape Up. Adam is a great interviewer. I like how he pushed for specific examples whenever I got too abstract. https://twitter.com/adamwathan/status/1212731802848288768?s=20
• 30 December 2019: To distinguish from other senses of the word. They fill the space left by the other, as opposed to “go well together.”
• 30 December 2019: https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-variable-scope A variable scope is a chunk of work you give somebody that isn't specified down to every detail, where they can make trade-offs about how to get it done. Time means how much time they have to do it.
• 30 December 2019: That is, if there's some understanding of process and responsibility wrapped around the question, the meeting can be smaller.
• 30 December 2019: There's still a question of how much meeting — who's involved. You might need 2-3 heads together. If you know who can make the call, how to end the discussion, and can get to the next step, that's meaningfully different than pulling, say, 6 people together to meet.
• 30 December 2019: Corollary: The less you delegate, the more often you have to meet. "Less" doesn't mean number of tasks. It's the amount of variable scope and time you give someone. https://twitter.com/rjs/status/1211503005838827520?s=20
• 30 December 2019: Not necessarily. Some communication and coordination can happen asynchronously and some can't. Depending on our understanding of the process we are within, more can happen async.
• 30 December 2019: Meetings and process are geometric complements. When you don't know what to do or who should decide, you call a meeting. When you know who's responsible and what happens next, you don't.
• 30 December 2019: Q: “Imagine you were to introduce @nntaleb ’s ideas over a short sequence of seminar discussions [ . . . ] What three or four themes would you pick out?” - @JoshHochschild A: https://twitter.com/rjs/status/1211462605396742145?s=21 (thread)
• 30 December 2019: Motivation for each (because this is fun): 1. To have a ruler for how bad a risk can be 2. To cut off classes of solutions that won’t work (don’t chase values of X, cap f(X)) 3. To identify where change (good/bad) comes from 4. Because any “solutions” will be scale-dependent
• 30 December 2019: Oh and incomplete without this fourth: 4. Scale transformation: different organization and policies called for at houshold, neighborhood, village, city, state, federate levels because of meaningful differences in structure and interaction.
• 30 December 2019: 1. Cascading vs isolated blowups: the “stans”, circuit breakers, precaution princip 2. Opacity: When we can only learn by interaction, risks of doing so 3. Minority rule: Novelty starts in tails, moves to body. Unpack: innovation, tolerance & intolerance, pos & negative cases
• 23 December 2019: The underscore notation is continuing to work well for breadboarding (see https://twitter.com/rjs/status/1203728061587427328?s=21 ) https://twitter.com/rjs/status/1203728061587427328 pic.twitter.com/HRarZ2u5r3
• 23 December 2019: https://twitter.com/rjs/status/1201920056944316417?s=20
• 18 December 2019: I think the challenge is that many people aren't used to thinking in terms of scale transformations. If you try to apply skin in the game at the level of individuals it can only mean incentive/disincentive etc. To get "filtering" requires going up to the scale of groups.
• 18 December 2019: "Over the years" -- exactly. The picture is relevant at the scale of years. People usually talk about "iteration" in a different context, inside the scale of weeks where projects happen. These are different worlds. We need a clear definition of "done" at the project-scale.
• 17 December 2019: We call the process of answering those questions “shaping” the project. We do it as a precondition for commiting time to a project. We don’t know the final form in micro but we know it in macro. That’s what we bet on.
• 17 December 2019: A “scope” in Shape Up (ch. 11) is a fun contradiction: a whole part. It’s a ‘part’ because it’s one piece of the final project. It’s ‘whole’ because it’s integrated vertically and does something. https://twitter.com/rjs/status/1207077933212241921
• 17 December 2019: The instinct to integrate early is right. But we should be integrating early on whole parts of the final form. https://basecamp.com/shapeup/3.2-chapter-10#integrate-one-slice
• 17 December 2019: This meme maybe might apply to the evolution of a whole product over time, from earliest MVP to fully-matured (maybe bloated) success. It does not describe how teams should iterate inside fixed time boxes.
• 17 December 2019: This popular meme is wrong when you work in a cycle under a deadline. You’d have to throw work away at each step. A tricycle doesn’t become a car. We don’t throw anything away inside a cycle (except for brief experiments). https://twitter.com/pasql/status/1207071400298778624
• 17 December 2019: Yes. Helpful to distinguish prototyping from iteration. Prototyping is when we build an experiment to learn what the right thing to build is. Iterating is a wider term than can but doesn’t necessarily include learning.
• 17 December 2019: Quote from a Shape Up adopter: “I finally feel ahead of things and much more confident about the work I give to the team; the understanding of the problem and validity of the solution. I have more time to think deeply about things, do research, and think strategically as well.”
• 17 December 2019: Obtaining demand-side insight takes time (to think, to talk to customers, etc). Supply-side problems cause you to have no time. Constant meetings, “grooming” tasks, trying to figure out what’s going on. Fix the supply side to create capacity for demand-side work.
• 17 December 2019: Demand-side insight gives you the most leverage (bang/buck). But you can’t take advantage of demand-side insights when you’re struggling to deliver on the supply-side.
• 17 December 2019: Two kinds of risk to differentiate: Demand-side risk: We chose the wrong thing to build because we misunderstood what the customer was trying to do. Supply-side risk: We failed to deliver what we chose to build at acceptable quality / within the time it was worth.
• 17 December 2019: We call that shaping.
• 17 December 2019: Iteration is meaningful when it’s nested within a hard deadline. Then we make trade-offs as we iterate toward a final, “done” version.
• 17 December 2019: Iteration is overvalued in our industry. “We‘ll make it better later” means it’s never done. Need to focus more on trade-offs. Trade-offs happen when we face a deadline and ask ourselves “What do we actually have to do to get this done?”
• 16 December 2019: Owning the time you schedule — with no interdependencies to other teams, customers, or vendors inside the cycle — is a prerequisite for fully doing Shape Up.
• 16 December 2019: Yeah the principles apply and you can apply tools from Shape Up across the board. But you can't make a bet and commit 100% of x weeks to a shaped project when the type of work your team does is request-driven or involves putting out fires.
• 16 December 2019: No. Shape Up is for product development. All our teams work in six week cycles, but that's mostly for reporting purposes on the teams that don't do product work.
• 13 December 2019: "A crucial aspect of this theory is the importance of movement." Great video by @rhyolight on the relationship between movement and object recognition. In Shape Up, the movement is the hands-on work we do that gradually reveals scope boundaries. https://youtu.be/66nueGWIWns?t=124
• 12 December 2019: I have an intuition that certain relational properties like trust require repeated interactions. So I'm guessing that things like trust could be called "convex" to the extent that they snowball up from those repetitions?
• 12 December 2019: Dumb question: what does convexity mean in this context? What does it mean for recurring meetings to be convex vs one-offs?
• 10 December 2019: I would move ASAP. My site went down. Support guy didn't explain what was happening at all. He told me to call them back. Called after another hour of downtime to check. Turns out the hardware is in Spain (?) and nobody will even see the ticket there until four hours from now.
• 10 December 2019: Just got badly burned by a web host with effectively no support ( @ionos_com ). Any tips for where to go for basic web hosting (static sites, a little PHP) these days?
• 10 December 2019: Yes. It's just about matching projects to the right people. Some projects call for different skills (eg. more fussy front-end interactions on this one, more back-end performance challenges on that one), independent of any junior/senior distinction.
• 9 December 2019: It’s mostly dive in the water and learn by swimming.
• 9 December 2019: Yes. The clear direction enables them to use their time better in the six weeks. It’s easy to underestimate how complex the real work of building it is and how many design decision they still had to make.
• 9 December 2019: The process is the same. You might choose a different project for a more junior team. And you might reserve a little more time for teachable moments or code review as they go.
• 9 December 2019: This quote from a reader is relevant: "In the name of empowerment and trust and autonomy we assigned big gnarly problems, but ended up eroding trust when it was impossible for teams to live up to our unclear expectations."
• 9 December 2019: Junior teams and expert teams need the same things structurally. The different is in which projects you give them, not how you work.
• 9 December 2019: Same thing.
• 9 December 2019: Some people think we shape work and put up guard rails for "junior" teams. That's a misunderstanding. We shape work for expert teams. This gives them the best odds of spending their valuable time on solvable problems instead of rabbit holes or open-ended questions.
• 8 December 2019: I know you don’t like me contrasting it with standard agile practice. You’ve pushed back more than a few times now. I’m going to keep doing it.
• 8 December 2019: I’m not finding it difficult :)
• 8 December 2019: There is overlap. But the important points that make a difference in our culture are orthogonal to agile — they’re about how we frame requirements (shape) a level above the team doing the work.
• 8 December 2019: It’s a different approach to the problem. Instead of turning faster when someone above says “that’s not what I want”, we work higher in the org so the direction is clearer and the teams can dig deeper in one place. Not better/worse. Different problem/solution.
• 8 December 2019: We eliminate the problem of changing requirements by making bets on shaped work. Requirements are set at the right level of abstraction and fixed for the project from start to finish. Within that, the team has latitude to detail the best solution.
• 8 December 2019: Q: Is Shape Up an “agile” framework? A: No https://twitter.com/rjs/status/1203751965861318657?s=20
• 8 December 2019: Agile grew up within engineering teams and adapted to the needs of engineering teams. Any response to the needs of cross-functional teams was bolt-on afterward.
• 8 December 2019: That’s why in practice the relation between design and programming in agile processes is high-speed waterfall.
• 8 December 2019: Fundamentally no, because agile is about responding to changing requirements, not about integration. Look through all the best agile stuff and you won’t find clear guidance about how design and development should interact.
• 8 December 2019: The deeper reason why Shape Up cycles are not just longer sprints. The shaped work defines “done”, the time wall (<= 6 week bets w/ circuit breaker) motivates trade-offs, and all functional roles self-organize to integrate inside the boundary. https://twitter.com/rjs/status/1203743877041139712
• 8 December 2019: Yes. The hill chart is for problem solving. There is little problem solving when you do strictly modular assembly because by definition the connection points of modules are pre-defined.
• 8 December 2019: Iteration vs. Integration pic.twitter.com/sHCoe50uUb
• 8 December 2019: New bit of breadboarding notation inspired by Rails. A “partial” is a place preceded by an underscore. Use it to spell out a subsection of a place or a repeating block. (See partials in Rails: https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials ) pic.twitter.com/92kAZMzJFU
• 8 December 2019: An underscore denotes a “partial” place – a section that appears on a place or a block that repeats. Borrowed from Rails partials: https://guides.rubyonrails.org/layouts_and_rendering.html#using-partials
• 8 December 2019: Re: estimating time to build: Adding: Thin-tailed. No ripple effects. Integrating: Heavy-tailed. Ripple effects between coupled parts. That’s why we track uphill progress of each integration (scope) on the hill chart. That’s where the risk is.
• 8 December 2019: (Credit @bmoesta for the ‘adding vs integrating’ language)
• 8 December 2019: Summary: pic.twitter.com/HBjweaPslw
• 8 December 2019: That is, you just make your new thing work and deploy without worrying what anyone else is working on.
• 8 December 2019: I should clarify... We of course run a suite of integration tests all the time. But that’s different than putting project-specific effort into integration. When you know two projects are orthogonal you don’t have to think about it.
• 8 December 2019: + Add, x Integrate Input problems: ( P1...Pn ) Orthogonalize as scopes: S1 = (P1 x P6 x P12 x P30...) S2 = (P2 x P5 x P8...) ...Sn Bucket new problems in a scope: Sn = Sn x Pn+1 Finish a scope: F = S1 And another: F = S1 + S2 Universe of unsolved work is bounded: U = S - F
• 8 December 2019: “Adding” and “integration” are different operations: Adding: Bolt working wholes together w/ no problem solving. Integration: Solve lots of problems to connect parts together into a working whole. Complex problem? Orthogonalize into integration problems that can then be added.
• 8 December 2019: “Make bets orthogonal” means before scheduling a project, declare which parts of the system are allowed to change and which ones should stay as they are. Check for overlap between parallel projects. No feature flags or integration testing needed. We’ve done this for 15+ years.
• 8 December 2019: Realized during the workshop this week that orthogonality vs integration underlies much of Shape Up. Avoid merge conflicts? Make bets orthogonal. How to draw scopes? Along orthogonal functionality. How to hammer scope? Integrate designers + devs in front of a hard deadline.
• 8 December 2019: A breadboard is a pattern language. pic.twitter.com/kqJOOk8N7g
• 8 December 2019: Or said without repeating the “win” language: When you and others integrate to participate in a process at a scale above you that is under selection pressure.
• 8 December 2019: When you and others are integrating with an objective to win at a scale above the scale of your integration.
• 6 December 2019: The energy was through the roof at our workshop on JTBD + Shape Up in Chicago the last three days. So many hands up with so many questions that it was a battle to get through the material. Thanks everyone who came. https://twitter.com/ericknopf/status/1203075023398821888?s=20
• 3 December 2019: These sections were added after 1.0: More backstory in the Introduction: https://basecamp.com/shapeup/0.3-chapter-01#growing-pains What about bugs? https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs QA is for the edges https://basecamp.com/shapeup/3.5-chapter-13#qa-is-for-the-edges New vs. existing products https://basecamp.com/shapeup/4.2-appendix-03#new-versus-existing-products Adjust to your size https://basecamp.com/shapeup/4.1-appendix-02
• 30 November 2019: https://twitter.com/rjs/status/1182476497006686209?s=20
• 30 November 2019: Notability and GoodNotes on iPad are both good.
• 30 November 2019: It was cited in an MIT Sloan Review article. Definitely seeing interest outside of software but no specific case studies to share yet.
• 30 November 2019: Anything that needs to be there, you can just indicate with a name. “Revenue graph.” If the graph has interactive elements you want to specify, you can make a ‘place’ for the graph (name with bar beneath) and reference it in the place where it’s embedded.
• 27 November 2019: This will be a must-read. https://twitter.com/bmoesta/status/1199741511195414532?s=20
• 26 November 2019: Talk about low-end disruption ... just heard about kids using Alexa to listen to made-for-kids podcasts because they're too young to have their own phones.
• 23 November 2019: They can choose to do something next that is not on any list at all. The lists are just things they discovered that they need to not forget. They aren’t exhaustive of work to do in the future. In other words, scopes start with zero tasks. The tasks are discovered by starting!
• 23 November 2019: The word doesn’t mean much if they aren’t.
• 23 November 2019: “Pull-based” implies a queue to work from. We don’t have a queue. See imagine vs discovered tasks.
• 23 November 2019: That is, we are not doing sprints within cycles. We are finishing things as we go, without any periodicity inside the cycles.
• 23 November 2019: This is not true. The irregularity inside a six week cycle is an essential feature to use time productively. 2+2+2 != 1+3+2 != 1+1+1+1+1+1 != 6 wks. This is a deep point. When and how you synchronize crucially impacts capacity utilization. https://twitter.com/johncutlefish/status/1198126971277824002?s=20
• 23 November 2019: No. Regularity (eg weekly cadence) inside the six weeks requires synchronization at the wrong times and reduces degrees of freedom. Better to let one thing take 3 days, another 8 days, without imposing periodicity.
• 22 November 2019: A Shape Up adopter spells out the truth about two-week sprints: pic.twitter.com/4ptaLwtgsn
• 22 November 2019: Validating gut, making sure I'm not biasing something too much. Helps to communicate to the team because it's the same actual logic as the contrast method but is easier to point at and inspect. Lastly in some cases, it catches cases that are hard to see via contrast method.
• 22 November 2019: Work related to jobs to be done theory. Competing Against Luck is a good intro.
• 22 November 2019: Yeah I did the contrast method first and got to the same jobs as the algorithm.
• 22 November 2019: "Put it on the backlog."
• 22 November 2019: We all take turns doing support from time to time to get exposed to the most common issues. Sometimes we dig deeper into things we hear from support. Here's a video about that: https://demandthinking.com/?offset=1504025010714
• 21 November 2019: There's some iteration. We'll review the full data of each story to check how it fits the cluster. If it really doesn't fit in the cluster, that suggests an error in the affinitizing or coding. Sometimes the coding looks off for a cluster but on review the story indeed fits well.
• 21 November 2019: 0 means it was not a casual factor in the story. In some cases somebody doesn't say it explicitly, but we can read between the lines that it was a 1 from other things they said.
• 21 November 2019: They're recorded as data points in each interview: pic.twitter.com/KmykH9VRBg
• 21 November 2019: Ok if you have something to show sometime, let me know.
• 21 November 2019: The full detail of the job (not shown here) gives you functional, emotional and social design requirements. Basically the problem definition that you use to judge solutions or changes against. See Competing Against Luck for a fuller picture.
• 21 November 2019: Cool happy to look at a case study if you have one.
• 21 November 2019: Blue are outcomes. Jobs are the vector from circumstance to outcome. In other words a job is: when I'm in this circumstance, I want this outcome. The starting point is part of it.
• 21 November 2019: Again, it's easy to tell other people what you think they should do. My question is, have you done it before? Show us the alternative you envision. https://twitter.com/rjs/status/1197316969311031297?s=20
• 21 November 2019: Do you have a data dashboard that tells you which users are successfully getting a particular job done and which aren't, that you rely upon with confidence?
• 21 November 2019: It's both. It's epistemic. In order to act, I need correct perception and knowledge of the world. I'm using whatever means I can to build up a picture that I trust is correct about what's going on. That knowledge is the basis for judging what's working and what changes to make.
• 21 November 2019: It's mostly coming from a perspective of risk management. I'd rather have less quantitative data but keep my qualitative eyes and ears open than misleading quantitative data and the illusion of knowledge.
• 21 November 2019: The model may or may not be useful. But the interpretation is definitely less foolproof. And if we based changes on it, we add more uncertainty on the second order. That's why I prefer regular qualitative sanity checks and one-off data projects instead of running model metrics.
• 21 November 2019: Numbers from usage data don't have a foolproof interpretation. Suppose we instrument messages posted per day. Account 1: (2,0,0,0,....,0,0,0,3), Account 2: ( 1,5,2,2,...,6,1,0). What does it mean? Depends on model assumptions. Lots of uncertainty.
• 21 November 2019: Lastly, that doesn't preclude us from doing all kinds of frequent and intensive deep dives to learn what works and what doesn't and how we can do a better job. It's just IMO a different epistemological category calling for different techniques and processes.
• 21 November 2019: So my approach is to only let a number "in" as a real metric if I feel deep in my gut I know what it means. And I put a lot of limitations on that. Maybe I'm simple minded but only a few numbers qualify for that.
• 21 November 2019: We can look at numbers based on that theory to tell us they are doing what the theory says they should being doing to be successful. But there is much more opacity and error and room for funny business at that level of detail.
• 21 November 2019: If they sign up, and use, and continue to pay .. and the trend doesn't go down ... it tell us we're doing something right. That's at the coarsest level. At the more precise level, we have a theory of why they do that. The theory can be wrong...
• 21 November 2019: "best indicator" — need to unpack. It's not the most precise indicator. It's probably the roughest, coarsest indicator. Eg they could be paying us to do an entirely different job than what we think. But it's the most foolproof indicator that there is some fit.
• 20 November 2019: I disagree. Signup + continued usage is the best indicator that some job is being done. Beyond that, I can describe very roughly what it looks like numerically when the job is getting done. But the usage is so incredibly varied that it becomes a Phd modeling problem.
• 20 November 2019: I find quant really helpful on the user outcome side to invalidate assumptions. Eg if I have a mental image that lots of customers are doing X, but then I look and nobody is touching that thing, that opens a research question to answer qualitatively.
• 20 November 2019: On the customer behavior side, there is far more data to look at than on the business side. For example we can look at use of different combinations of tools over time as proxies for some successful outcomes. Most of our understanding of satisfaction comes from qualitative data.
• 20 November 2019: The big numbers — signup and cancellation — tell us the answer to both sides. We aren't a monopoly. People pay us if the product is valuable and leave when it's not. Then, on both sides, we can dig deeper into all kinds of data if we have more specific questions.
• 20 November 2019: My impression from your Q is you're assuming a big asymmetry in how we look at what's good for the business vs what's good for the customer. That's just not the case. I'm sure you can find lots of companies where that asymmetry exists. That's not us.
• 20 November 2019: There's a rough directional sense of whether things are going in the right direction or not. There's reporting on the big numbers that matter. It's not much more rigorous than that.
• 20 November 2019: Exactly.
• 20 November 2019: These are the basic questions we've been looking at since v1. You ship, then you talk to somebody who tries it, and you see if they actually use it the way you thought they would or not. We've done that with friends on a beta all the way to formal research projects.
• 20 November 2019: At that level of abstraction there isn't much of a conversation. Because I would just say "we already do."
• 20 November 2019: I'm game for that but we need something concrete on the table. A case study or something that shows the kind of work you would like to see other people do more of.
• 20 November 2019: But perhaps you mean something more specific by "managing user value" and there's something you want to see companies do more of. Whatever that is, maybe you can show an example and say "this. do this."
• 20 November 2019: Showing real work is the best "content."
• 20 November 2019: Yeah I cringe a little when you suggest we aren't "managing user value" enough (not sure what they means) because that's my main responsibility and focus. Having a different approach to it doesn't mean we aren't doing enough of it.
• 20 November 2019: I find it helps to swap the spectrum metaphor ("is your process intuition vs data") with a patch metaphor (where/when do you use intuition, where/when do you use data). Key insight I got from @yaneerbaryam . The research > shape > bet > build loop is compatible with both patches.
• 20 November 2019: * are in the same class.
• 20 November 2019: Every hire interview is also a fire interview. They stopped doing one thing to do something else instead ("switched"). Assuming you interview on the new hire, all the stories in the same class and the method will work on them together or separately.
• 20 November 2019: *causal factors.
• 20 November 2019: The important thing is that the columns correspond to casual factors so that differences in the vectors correspond to differences in the causality of the story. Algorithms are garbage in garbage out. The interview data is most important.
• 20 November 2019: Statistical tools like JMP can do Ward's method in a couple clicks. That's where the cluster column came from in the spreadsheet.
• 20 November 2019: Nothing's been published yet. Short version: Think of each story as a vector (1,0,1,...,0). You can calculate distance between the vectors using diff methods. That's the basis for clustering which stories "near" and "far" aka similar/dissimilar.
• 20 November 2019: It's easy to tell other people to do more. It costs nothing to say that. But the person you tell to do more has to do less of something else to make the time. We all only get the same 24 hours in a day. I'd rather see you offer a different example than push back on us.
• 20 November 2019: You’re assuming indifference. Everything isn’t a mystery. Sometimes you know what needs to be fixed and you fix it and you don’t have to run a survey afterward to know that you fixed it :) Othertimes it’s not clear and you need to research.
• 20 November 2019: At Basecamp, sometimes we don't. Sometimes we ship something, believe it's an improvement, and walk away happy without feeling we need to do any extra validation step. Other times we do user research, qual or quant, to learn if the thing works the way we intended.
• 20 November 2019: You seem to assume that the user is left out somewhere but that's incorrect. No project has value unless a customer values it. The whole thing is about working at the win-win intersection between what is good for the user and what is good for the business.
• 20 November 2019: We called that "shaping projects."
• 20 November 2019: @SamuelHulick @chriscbs @jasonfried Chris described a hierarchy like this: JTBD > Biz goals > Shaped projects That puts the user at the top. If what we're doing doesn't match what the user wants, there's no demand in the picture and therefore no value.
• 20 November 2019: The JTBD is the user's desired outcome.
• 20 November 2019: "From this perspective, changes in discounting behaviour arise from actual changes of circumstance, not of mind." Nice summary of the discounting paper by the @LdnMathLab crew, sparked by a discussion about ergodicity economics and JTBD w/ @ole_b_peters . http://lml.org.uk/paper-announcement/microfoundations-of-discounting/
• 20 November 2019: Sure.
• 20 November 2019: Yes: https://m.signalvnoise.com/how-i-wrote-shape-up/
• 20 November 2019: 1. Columns come from the interviews, not prior work. They are the causal factors that were discovered in the interviews. 2. Only buyers, no users. 3. Only people who actually bought in the past. It's empirical — what actually happened in their process.
• 20 November 2019: Start with Competing Against Luck for background. Then seek out one of @bmoesta 's workshops.
• 20 November 2019: Yes and yes.
• 20 November 2019: JTBD interviews aren't scripted. More like an intelligence interrogation. See Competing Against Luck to learn more.
• 20 November 2019: Research like this completely takes over your time. Usually not practical for cross-functional teams to participate. It's an input to the shaping process,
• 20 November 2019: The clusters are algorithmic. Hierarchical clustering with Ward's method.
• 20 November 2019: Data from each interview is in a home-grown app. Plus transcripts. There's a detailing step of aggregating hire/fire criteria, more about/less about for each job. But I haven't gotten to that yet on this project. pic.twitter.com/l769cAmE5Z
• 20 November 2019: With infinite time we could do anything! :)
• 20 November 2019: The job, btw, isn't just this one sentence. It's a big bundle of data belonging to this set of stories. Includes words they use, features they use, things they don't do, things that must happen, things that don't matter, etc.
• 20 November 2019: Or if there is a specific struggle or weak point in the product/marketing that came up in the interview, we can (a) look at that as a potential project to shape and (b) use the job to put it into context so we understand what matters about it.
• 20 November 2019: The jobs are lenses. Like a persona but causal — describing a situation instead of attributes of a person. Next step depends on what we're working on. For example with marketing, we could pick a job to talk about and then extract lots of specific customer language to work with.
• 20 November 2019: Requires background knowledge in JTBD (see Competing Against Luck for a start). Orange columns are abstracted 'pushes' and the blue abstracted 'pulls' from the interview data (via an affinitizing process). Interviews (rows) are coded 0 or 1 if that force played a causal role.
• 20 November 2019: This is the highest level summary. There's a ton of data and specific pain points / opportunities in the individual stories.
• 20 November 2019: The first one is about "me" and "my time." Don't bother me, find it yourself, make this easier on me. Second is about setting ourselves up to succeed as we try to do more. Third is about aspiring to a model you look up to when designing how your new team works.
• 20 November 2019: Just ran another round of job-to-be-done interviews for Basecamp. Coded stories and first cut of the three jobs that came out: pic.twitter.com/hlX3ZVNjnd
• 20 November 2019: Interesting: A real-estate developer wants to differentiate by creating car-free neighborhoods. "1,000 Residents, 0 Private Cars" https://medium.com/culdesac/introducing-culdesac-3fbfe7c4219c
• 20 November 2019: Can you do me a favor? We're trying to learn how Shape Up has impacted teams so far. If Shape Up has influenced the way you think or work, would you fill out this short survey to tell us about it? https://www.surveymonkey.com/r/basecamp-shapeup
• 19 November 2019: Here's a typical example of how a big open-source software project manages community: https://rubyonrails.org/community/ - Forum (Google Groups or Discourse) - Chat (IRC or Slack) - Yearly conference
• 19 November 2019: I’m giving a talk about Shape Up with Q&A (via video) at the Product Tank meetup in Raleigh on Thursday. https://twitter.com/ProductTankRTP/status/1196593712542994432?s=20
• 19 November 2019: Fixed now.
• 18 November 2019: Fascinating thing re: @DescriptApp : For reading purposes, the machine transcription isn't good. But the transcripts are for navigating, not reading. 80% accuracy is more than good enough for navigating. Love orthogonal measures of performance like that. https://twitter.com/rjs/status/1196497605083054080?s=20
• 18 November 2019: Will have a look, thanks.
• 18 November 2019: Edited the latest Demand Thinking episode with @DescriptApp over the weekend. It's one of those tools that completely changes your expectations about a whole software category. Can't imagine editing any audio just by looking at waveforms after this.
• 18 November 2019: New Demand Thinking Episode 4: Metrics Aren't Projects With a fascinating point of view from @chriscbs on the relationship between targeting a number and shaping the projects to do next. https://demandthinking.com/episodes/2019/11/18/episode-4-metrics-arent-projects
• 17 November 2019: From a success / survival standpoint.
• 17 November 2019: Eg in Shape Up, the 6 week bets are technically fragile. They require planning and prediction. They sometimes fail. But the circuit breaker means they can fail without ripple effects. Local, limited failure means more optionality and more lessons learned.
• 17 November 2019: Reading @nntaleb ’s Antifragile again. Surprised to notice now that fragility isn’t bad — antifragile systems are necessarily made of fragile components. Fragility at the wrong scale is what’s bad.
• 14 November 2019: Been back pretty often. Doing a workshop Dec 4-6 there and I'll be back again in January.
• 14 November 2019: Long term who knows but yeah I'm living there now.
• 13 November 2019: It means to create channels in something for a productive purpose.
• 12 November 2019: Hypothesis: The subconscious pattern matching is the default. When it's not sufficient and the problem deserves more energy, some explicit work needs to happen to acquire new information. Then the new information canalizes the existing pattern matching ability toward a solution.
• 10 November 2019: 3-5 people
• 8 November 2019: This section on bugs applies equally to small little tasks: https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs
• 6 November 2019: Question about betting from @raserapedro : “Does having only a small circle of people defining what gets worked on for the next cycle impact the teams’ feeling of purpose? By that, I mean not having a say on the matter.” Answer: https://twitter.com/rjs/status/1192159478075969536?s=21
• 6 November 2019: It can help to look at your size + growth. It’s normal for teams to do “everyone decides” when they are small. When they are larger this doesn’t work anymore. And there can be an awkward teenage phase in between when you’re too big for “everyone’s involved” but haven’t faced it.
• 6 November 2019: Reframe it in terms of the time, knowledge, work, and skin in the game different people have instead of power. Transacting a decision takes one moment. Arriving at a decision takes time. A programmer who codes all week doesn’t have time to talk to customers, model strategy, etc.
• 6 November 2019: This @wrathofgnon sure knows how to make a Twitter thread: https://twitter.com/wrathofgnon/status/1191943413308022785?s=20
• 5 November 2019: A reader asked if Shape Up can apply to client work. Answer: pic.twitter.com/atUfg7w2vU
• 5 November 2019: I’m seeing a lot of people treat stories as tasks. Things to define and put in a queue for someone to check off. My point is that the higher “what we’re trying to do” isn’t a task, it’s the source of tasks.
• 5 November 2019: At scale of 6 weeks (an entire project) it’s a pitch: the description of the shaped project. At the scale of days (~< 1 week), it’s a scope: one vertical slice, orthogonal chunk, to complete. At the level of < 1 day, it’s tasks. Individual things to make sure to execute.
• 5 November 2019: Work at different scales takes different forms. You don’t start a painting with “brush stroke at bottom left corner.” You start with the idea: “a house.” Then a sketch, an underpainting. Finally individual strokes of paint. Ditto product dev. It’s not all tasks/stories.
• 5 November 2019: The idea that a project is made up of multiple “stories” is incoherent. A project that has one team and one deadline needs one “story.” The story of what we’re getting for the time spent. The pitch. The bet. One story focuses everyone and enables the team to make trade-offs.
• 5 November 2019: In other words, don’t start a project by writing a bunch of stories or tasks. Start a project by describing the whole. Then start on the whole, and lots of little tasks will pop up. https://twitter.com/rjs/status/1191843648586936320?s=21
• 5 November 2019: We call these macro things “scopes.” (See Shape Up) Even the scopes aren’t given up front. You start by digging into the shaped project as one whole thing and deciding where to start.
• 5 November 2019: Work doesn’t start with stories/tasks. Work starts with a macro thing you want to make. Like “send a new invitation.” Then out of working on that, a bunch of small scale things appear that you have to remember to do. Those are the tasks. https://twitter.com/rjs/status/1191842161647468544?s=21
• 5 November 2019: Re: imagined vs discovered tasks... There’s a difference between using tasks to set direction vs. to remember things. We don’t need any tasks to start building something. Then as we get in the weeds, we discover lots of things we must not forget to do. Those become our tasks.
• 5 November 2019: http://basecamp.com/shapeup
• 5 November 2019: Clarity comes from asking ourselves: Who actually decides what we’re going to build and pursue? Who decides what we spend time on? You can keeping having 4-hour all-hands “sprint planning” fiascos or start thinking harder about shaping + betting. https://twitter.com/rjs/status/1191507983613620224?s=21
• 5 November 2019: The less deliberate leadership is, and the more overloaded the builders are, the more you need a Product/Project Manager whip to try and keep everybody in line. https://twitter.com/rjs/status/1191503374790750209?s=21
• 5 November 2019: Looks like in 80% of cases, the CTO is the actual “product owner.” Why? They control the programmers’ time. Whoever controls peoples’ time decides where the product goes. https://twitter.com/rjs/status/1191508917429260289?s=21
• 5 November 2019: You aren't a "Product Owner" if you don't actually own resources. That is, if you yourself can't go schedule a programmer and a designer to a project for x weeks. These Product * titles are mirage-like. Lots of talk about vision/strategy, mostly just playing Tetris (time mgmt).
• 5 November 2019: The work that actually moves a product forward: 1) Outlining the design+tech concept for a feasible project (shaping) 2) Scheduling the project w/ resources you control (betting) 3) Executing the details (building) Everything else should be looked at very critically.
• 5 November 2019: Product Managers. But in most cases those are really just Project Managers in practice.
• 4 November 2019: It seems many PMs today live off of lack of clarity and confusion in the org. If engineers have more work than time, plus unclear direction, you need someone to poke them with a stick and maintain priorities. But with well-shaped work and autonomy, this is totally unnecessary.
• 4 November 2019: I'm hearing from Shape Up readers that it's giving them more clarity about roles and "where they sit" in the company. One big takeaway: "Product Manager" should be unbundled. If they aren't shaping, and they don't own resources to make bets, what are they doing?
• 1 November 2019: Yeah. The screener helps us (1) eliminate people who don't qualify for JTBD interviews (eg if they weren't the decision maker or bought it in the past) and (2) make sure we have enough variety on the dimension we care about.
• 1 November 2019: It’s not a narrow thing. Lots of room to message in different ways and try different things.
• 1 November 2019: Getting good crispy answers to this question (instead of “what’s your industry?”) pic.twitter.com/JAfLdOZX6K
• 31 October 2019: Spreadsheets are for managing the process until people get scheduled (using Calendly for that). Then the actual interview data goes into a custom tool.
• 31 October 2019: Yeah spreadsheets.
• 31 October 2019: What do you mean by maintaining a status? Right now I'm reaching out for a one-time purpose of interviewing.
• 31 October 2019: (*conservation, I meant.) Yes.
• 31 October 2019: Interesting pattern starting to form: Focusing on streams of work vs companies or industries. Teams within very different companies can have similar structure. Teams within the same company can have different structure. The work is what characterizes. https://twitter.com/zealigan/status/1190007747183558657?s=20
• 31 October 2019: Does this conversation lens allow for the entire pie to grow/shrink? Or is that outside the scope of the argument?
• 31 October 2019: Working on a survey to screen candidates for a round of Basecamp customer interviews. Noticing the standard "what's your industry?" question is at the wrong scale. More useful: what kind of work does your team do? Suspect more overlap in these answers. Eg "marketing team."
• 30 October 2019: We have thoughts on that for the future, but there isn't a good solution other than screenshots today if you want to show the chart to people who aren't on the project.
• 30 October 2019: By the definition I had in mind [cat, sed, grep] are modular in that example because they conform to a standard interface [stdin, stdout, pipe]. By contrast, integration would be diving down a level to write a new command vs composing at the CLI.
• 29 October 2019: Yes.
• 29 October 2019: From a business POV, see The Innovator's Solution by @claychristensen , Chapter 5. From a complex systems science POV, see Making Things Work by @yaneerbaryam , Chapter 5.
• 29 October 2019: We're all taking what we can understand and use with the short time we have. It's amazing that something like that catches on at all and persists through time in any form.
• 29 October 2019: Practically speaking, it's handy to use "kanban" as a shortcut for ad-hoc, just-in-time scheduling as opposed to planning in sprints or cycles.
• 29 October 2019: 🙏
• 29 October 2019: No plans for that right now.
• 29 October 2019: - Type of work: What the project calls for vs. what they’re good at - Variety: A big feature if they have worked on small things for too long - Availability: Who’s on vacation - Criticality: How much room for error is there (junior vs senior)
• 29 October 2019: A-ha! /cc @bmoesta
• 29 October 2019: Is this relevant? https://basecamp.com/shapeup/2.2-chapter-08#are-the-right-people-available
• 28 October 2019: Re: the recursion, I mean if the broader containing context is "product development in 2019" there isn't a one-size fits all approach. But there might be on the order of ten patches that cover most of the space. That is, patches of space assume a boundary that defines the space.
• 28 October 2019: Yes. At the same time, context is patchy. No one-size fits all, but also not millions of different contexts (assuming, recursively, a broader containing context). So given a patch of context, there could be a matching patch of best-practice.
• 28 October 2019: We solved that for ourselves with Shape Up https://basecamp.com/shapeup
• 28 October 2019: Integration is how you get novelty. Modularity is how you get repetition (aka scale). https://twitter.com/rjs/status/1188964501179076608?s=20
• 28 October 2019: For people who like solving problems and doing new things, integration points are where all the action is. You don't want to draw a design and set it on a conveyer belt for step n+1. You want to plug it in! You don't want to just build a feature. You want to merge and ship it!
• 28 October 2019: Shape Up presumes that the one doing the betting has a pool of designers and programmers under their control wrt to scheduling. If you don't control the resources, you can't integrate them inside a time box to make a bet.
• 28 October 2019: Methodologies don't map to companies. They map to specific kinds of work under certain types of resource availability. Different types of teams. It's just that small companies with one team often need to start with one way of working for that one team.
• 28 October 2019: A team came to me for help implementing Shape Up and I suggested they use kanban instead. Why? The resources they needed to integrate (to make a bet) cut across the firm's boundaries. They needed to wait on a vendor every step of the way.
• 28 October 2019: Also love how, when you're working in an entirely new area, you have to solve challenging new integrations but can also cut a lot of corners. People are willing to make the trade-off and, eg ignore the bad bud fit for other brand-new behaviors. That's asymmetric competition.
• 28 October 2019: Apple is being the most Apple with the Watch and AirPods right now. Both started with unusual, highly differentiated, sparse feature sets. Eg the W1/H1 chip in AirPods for better pairing. Only later did we the get "obvious" things like custom-fit tips or always-on watch face.
• 26 October 2019: @AdamStddrd built it with Jekyll and designed the templates.
• 23 October 2019: Demand Thinking is back (after a long break!) with a new episode. You can now find us in your podcast app of choice now too. https://demandthinking.com/episodes/2019/10/23/episode-3-the-slapdash-meeting
• 22 October 2019: Vs planning at macro and leaving the micro details to be filled in ad hoc prevents the cascade.
• 22 October 2019: Any further reading in this specific point? Been trying to show how this applies to project planning under opacity. Something about how errors at micro scale cascade into macro problems.
• 17 October 2019: It’s just a question of where you have scarcity and whether you feel the time is well spent. Could be very hard to get programmer time but you have lots of time for shaping, or could be you have many things to shape so you need to be more discriminating about what to shape now.
• 16 October 2019: Yes. For example it’s possible to debate solutions for a tiny interface issue for hours and of course this doesn’t make sense. So the principle applies to shaping as well. Just less formally. The point is to be conscious about what we choose to spend our time doing.
• 16 October 2019: Thanks. Updated version of that is here: https://basecamp.com/shapeup/1.3-chapter-04#breadboarding
• 12 October 2019: We used to track small batch projects all in one Basecamp project. Now we use separate projects for each small batch project, even if quite short, so we can properly track scopes with separate lists on the Hill.
• 11 October 2019: Academia is being kind to Shape Up. Here is a piece in the MIT Sloan Review that cited it. pic.twitter.com/LaHWO7zkUj
• 11 October 2019: This was quite early in the process of articulating shaping (before the book was written), but it’s always a blast to talk with @bmoesta and an honor to speak on a Harvard platform. https://twitter.com/bmoesta/status/1182264089948692485?s=21
• 10 October 2019: Maybe putting some better examples out there will at least help out the people on the leading edge who care about good work and are interested in the deeper questions.
• 10 October 2019: It looks like lots of companies hire UI/UX without knowing how to judge quality. Surface over substance. I can't pretend to solve that. I'm just talking about how to better show what the real work is. Whether companies care or not is another question.
• 10 October 2019: https://basecamp.com/shapeup/1.3-chapter-04#breadboarding
• 10 October 2019: Finished design work is extremely hard to evaluate. The styling detracts from the deeper decisions. Without declaring an appetite, you can't tell a steak from a hot dog ("it was supposed to be a short project!"). Better to show breadboards, fat marker sketches, and write more.
• 10 October 2019: Realized today that a pitch is actually a good format for UI/UX portfolio work. Rough sketches, problem, solution, appetite. Shows the thinking and the rationale, the affordances and flows, not just a bunch of visual styling. https://basecamp.com/shapeup/1.5-chapter-06#examples
• 9 October 2019: Updated the introduction of Shape Up with more backstory on Basecamp and how our way of working evolved: https://basecamp.com/shapeup/0.3-chapter-01#growing-pains pic.twitter.com/ekNQaf0FvL
• 9 October 2019: Thanks for sharing. Really glad to hear about your progress.
• 9 October 2019: Yes, of course. If I had to append "... given context X Y Z and not in every case ..." to every Tweet, no message would get out and it certainly wouldn't ring very loud. :)
• 9 October 2019: I would go even further — just making software do what it's supposed to do is very difficult.
• 9 October 2019: There are lots of ways to be polite without hiding/transferring risk: "What do you think about adding a permission option?" "Do you think it's reasonable to add a permission option to this?" "Would you have some time to chat about maybe adding a permission option?"
• 9 October 2019: I'm not arguing against politeness. I'm talking about a specific context: adding scope to a software project under the cover of the word "just." "Let's just add a permission option" is very different from "Can you just have a look at the schedule for tomorrow?"
• 9 October 2019: Agree the function is useful but "just" has the side effect of implying that the work is smaller or easier than it is. This hides and transfers risks. Better to find another way to handle the social nuances of the ask.
• 9 October 2019: Here’s one we haven’t mentioned in a while... “Just” is a four-letter word. “We’ll just...” “Can you just...” Usually invoked to create the illusion something is easier than it really is in order to push it through.
• 9 October 2019: Kano is deep because it’s also dynamic. There’s the second order over time: What is excitement today becomes performance tomorrow because basic later on.
• 9 October 2019: Kano is important because it protects us from overinvesting in the wrong things (basic quality) or sales pitching the wrong thing (sell the performance, not the delight).
• 9 October 2019: It’s not fashionable, but Kano treats this well. Nobody will ever be “delighted” by brakes on a car. That’s “basic” quality. Then there’s “performance” quality where the user compares. Eg acceleration or interior space. Last is “excitement” quality for unexpected delighters.
• 8 October 2019: Re: the “barbell” framework ... We know what “no risk” is. We know what “high risk” is. We don’t know what “medium risk” is. “Medium” can still go to zero. Applies to hill charts. Anything that’s not over the hill can’t be trusted.
• 8 October 2019: This video is an excellent primer on the main ideas of @nntaleb ’s Skin in the Game. https://www.youtube.com/watch?v=a3YOMe4PnKE
• 8 October 2019: Somebody has to call out things that don't work, and I'm happy to play that role sometimes.
• 8 October 2019: That's your book. I think we have different approaches.
• 8 October 2019: Shape Up doesn't teach you to shape. It offers a repeatable way of working that builds in more time for the things we thought were important to reserve more time for.
• 8 October 2019: If you want to learn to program, you don't adopt Scrum, you pick up a programming tutorial! Same with design and Shape Up.
• 8 October 2019: All models assume skill in the actual work.
• 8 October 2019: Those who want to blindly follow an example will still do better by blindly following a better example.
• 8 October 2019: "We" can't provide time, resources, and experience to other businesses. And I'm not making a comment about off the shelf frameworks in general. I'm talking about how agile/scrum doesn't include time to think in the off the shelf version.
• 8 October 2019: Exactly. That's why our framework builds in more time to think.
• 8 October 2019: Same thing again: https://twitter.com/rjs/status/1181413903407833088?s=20
• 8 October 2019: People reach for an off-the-shelf system and implement it in an off-the-shelf way in exactly that situation where they don't have those things.
• 8 October 2019: Your suggestion assumes somebody has time, resources, and the right experience to work on this problem. That's not always true.
• 8 October 2019: Yes. The other aspect is people forget that agile was made by programmers for programmer teams. Not product teams. A product team with strategic direction and integrated design + programming requires a different structure that accommodates all three aspects of the work.
• 8 October 2019: Many companies adopt something like scrum when they find themselves scrambling with too much work and no system. "Give us a machine to feed this work through." If the machine doesn't build in time to think, all capacity gets used up building. Then no room for vision.
• 8 October 2019: There is a spectrum of adoption from whole-hog-cargo-cult to cherry-pick-and-custom-fit. Contextual factors that place someone on the spectrum include: how experienced the team is, how much time they have to think, whether their biz frames dev as cost center or value center, etc.
• 8 October 2019: I have the feeling we're talking past each other. Might be at the limits of how far we can get on Twitter because we're assuming different contexts or trying to make different points.
• 8 October 2019: The issue is this: when a small team grows as a business, they reach a certain size where they can't wing it anymore. Then they need to adopt a more fixed structure. If that structure doesn't give them room to think or complete meaningful-size things, then it causes problems.
• 8 October 2019: Vision doesn’t fit into a 2-week sprint system. That means if you find yourself at a scale when you need to create a machine to do work, that’s all the machine will do. Those who manage to set vision beyond that and execute on it do so outside the borders of prescriptive agile.
• 8 October 2019: It’s not complicated. Go try and learn “agile” from a popular introduction or set up a tool like Jira designed for agile. All the prescriptive structure is around sprints. There’s no “do this” structure for the scale above that.
• 7 October 2019: A "little too much agile" means not enough vision and major milestones. https://twitter.com/stubblefriend/status/1181313291420930048?s=20
• 7 October 2019: Here’s a piece on that: https://m.signalvnoise.com/the-fidelity-curve-how-to-weigh-the-costs-and-benefits-of-creating-ui-mockups/
• 5 October 2019: This is a step toward bridging jobs-to-be-done theory and economics. The more a decision-making model articulates context and time, the less you need “irrationality.” Pushes/pulls may map to quantities growing at different rates. https://twitter.com/rjs/status/1180577669278158850?s=21
• 5 October 2019: A deep paper by @ole_b_peters @alex_adamou @bermanjoe @diomavro injects reality into the foundations of economics: put circumstances and time frames at the center of decision making. These are more fundamental than preferences/biases/psychology. https://www.researchers.one/article/2019-10-7 pic.twitter.com/ggzI6VkdAR
• 4 October 2019: It's a big enough spend and time commitment that I can imagine it takes everyone who's interested a little time to work out the logistics.
• 4 October 2019: It's the art of what's possible. For whatever team you can put together, you can do better shaping, de-risking, betting etc so you get better outcomes there. It's better to have one good model that sets the bar for the rest of the company going fwd than try to change all at once.
• 4 October 2019: Yes, that's right.
• 4 October 2019: A complex system is one where our assumptions of independence break down. That's why programmers talk so much about orthogonality, decoupling, factoring, etc. We simplify by creating independence. https://twitter.com/yaneerbaryam/status/1179889703169986560?s=20
• 4 October 2019: Ah, no. Those edits I listed are all of them. Will only be making a couple more big edits before committing to the text and moving on for 2019.
• 4 October 2019: Jekyll is open source. The templates are custom.
• 4 October 2019: I’m editing the git repo for the site directly. Markdown files rendered by Jekyll.
• 4 October 2019: The additions so far are: What about bugs? https://basecamp.com/shapeup/2.2-chapter-08#what-about-bugs QA is for the edges https://basecamp.com/shapeup/3.5-chapter-13#qa-is-for-the-edges New vs. existing products https://basecamp.com/shapeup/4.2-appendix-03#new-versus-existing-products Adjust to your size https://basecamp.com/shapeup/4.1-appendix-02
• 3 October 2019: Yes this is TBD as the case studies mature.
• 3 October 2019: @brhea Here's the update we talked about on the podcast: https://twitter.com/rjs/status/1179902181756915712?s=20
• 3 October 2019: Sorry it just moved here: http://basecamp.test/shapeup/4.2-appendix-03#new-versus-existing-products
• 3 October 2019: Here it is: https://twitter.com/rjs/status/1179902181756915712?s=20
• 3 October 2019: New appendix: Adjust to Your Size. On how small startups should apply Shape Up differently than bigger companies. * Basic truths vs. specific practices * Small enough to wing it * Big enough to specialize https://basecamp.com/shapeup/4.1-appendix-02 pic.twitter.com/pUIXxahg4p
• 3 October 2019: Did that: https://basecamp.com/shapeup/4.1-appendix-02#new-versus-existing-products
• 3 October 2019: I considered it but I'm nearly at the end of the changes. Going to mark this the 2019 edition and put it bed soon so we can move on to less malleable formats like audio and print next.
• 3 October 2019: This came up in the podcast with @brhea : The work of figuring out what the RIGHT work is ... IS work. Some people worry that if they're not making a wireframe or writing code, they're not doing real work. Shaping is work. Two people breadboarding in a room are working.
• 3 October 2019: Writing Shape Up as a web edition, with constant questions and feedback, has been good for the text. Wrapping up a new section right now that specifically addresses the scale-dependency of certain practices — what size teams shouldn't use six weeks etc and which should.
• 3 October 2019: Twitter, used well, is a distillery. A pith machine.
• 3 October 2019: The nights are a secret of multi-day workshops. Sleeping on the material makes it go deeper. Connecting over dinner/drinks builds rapport. People are more open. It's a special atmosphere you can't create in one day. Join us Dec 4-6 in Chicago: https://twitter.com/bmoesta/status/1179492555483942915?s=20
• 3 October 2019: Bob and I really enjoy doing these combined JTBD + Shape Up workshops. But there won't be many of them. It's just hard to set aside the time. Come to Chicago if you can Dec 4-6. We'll go deep for three days with a small group at Basecamp's office. https://twitter.com/bmoesta/status/1179492555483942915?s=20
• 3 October 2019: No plans for other workshops right now.
• 2 October 2019: Full book on our process here: http://basecamp.com/shapeup For resource allocation and scheduling, see especially Chapters 7 and 8 on Betting.
• 2 October 2019: Has to do with the fact that work is discrete. There is a "smallest unit" to getting anything meaningful done. If something you expected to take 2 days takes 3, it can screw up a week. Makes it hard to make precise bets at the smallest scale.
• 2 October 2019: You lose a different kind of optionality down at that scale because you have to guess exactly correctly how to fill the two weeks with work. There's too little room for error.
• 2 October 2019: It turns into a straight jacket. You can't get much done when you have to stop everything and regroup every two weeks.
• 1 October 2019: Lots of overlap. Antifragile turned me on to NECSI via a mention of @yaneerbaryam . Nassim's work, his RWRI circle, and NECSI helped me articulate ideas + sparked Hill Charts. Nassim's twitter led me to @ole_b_peters . There's overlap w/ his work and @bmoesta re: decision making.
• 1 October 2019: The opposite is also true at the smaller scale: A single six-week option is more valuable than three sequential two-week options.
• 1 October 2019: Technical comment by @nntaleb that's consistent with how we bet on projects six weeks at a time, not longer. Source: https://www.edge.org/conversation/nassim_nicholas_taleb-understanding-is-a-poor-substitute-for-convexity-antifragility pic.twitter.com/LZEx70gtAe
• 1 October 2019: Added another section to Shape Up because I kept getting this question from readers: How do you handle QA? Programmers and designers are responsible for quality. QA helps us catch edge cases. It's a level-up, not a gate. More here: https://basecamp.com/shapeup/3.5-chapter-13#qa-is-for-the-edges pic.twitter.com/JzA89O6f6Q
• 1 October 2019: Ditto no product, framework etc. And yeah the interesting part is defining the zone of applicability.
• 1 October 2019: “No model covers all cases” is a kind of basic relativity principle that I haven’t seen well articulated (except in the extreme by Gödel).
• 1 October 2019: I wrote a piece on it here: http://feltpresence.com/functions.html
• 28 September 2019: We keep things simple. Our designers create HTML/CSS directly in Rails views. That leads to the minimum number of handoffs and translation steps. May not be possible for everyone but it's the lowest tax + tightest feedback loop way to go.
• 27 September 2019: "Choosing College" sets a new standard for how truly helpful a book can be. Reminds me of @ltoddrose 's work on individual pathways to progress. Instead of giving you one answer, it gives multiple examples to figure out where you are and what to do next. https://twitter.com/rjs/status/1177692236902883328?s=20
• 27 September 2019: "Choosing College" by @bmoesta and @michaelbhorn is a fascinating jobs to be done case study. The deepest end-to-end jobs project that's ever been published. 200 interviews broken down into five jobs, spelled out in full detail. Highly recommended. https://www.amazon.com/Choosing-College-Learning-Decisions-Throughout/dp/1119570115
• 27 September 2019: A number of people have asked: How did you use Shape Up to build Basecamp 3? Does it apply to new products? Here's the answer: https://m.signalvnoise.com/how-we-shaped-basecamp-3
• 26 September 2019: Emotional and social contrast: from closed-door euphoria to reality check. pic.twitter.com/PoLMkjKYnA
• 26 September 2019: Was talking to @chriscbs about this stage yesterday and he called it the "euphoria" part. You're working with someone with the exact same context as you in a closed-door session. You're on the same page and just flying with ideas. pic.twitter.com/LLJ8F9De3z
• 26 September 2019: Been tweeting the major updates. Trying to wrap this up so we can go to less malleable formats (audio and print) sooner than later. Just this other update so far: https://twitter.com/rjs/status/1176661079885115392?s=20
• 26 September 2019: Just revised Chapter 5. Made it clearer that whoever did the shaping presents it to technical people for feedback. Now the flow is clearer: Shaping: Two people jamming in a room De-risking: Opening it up for input from experts Pitching: Working alone https://basecamp.com/shapeup/1.4-chapter-05 pic.twitter.com/uH5dvE5V3Y
• 26 September 2019: Multiscale properties in time = properties at different scales change at different times?
• 26 September 2019: Amazing quote from @bmoesta about innovators: “When they don’t know what to do, they know what to do.” Eg: taking on multiple perspectives, modeling cause and effect, uncovering demand, prototyping to learn, making trade-offs.
• 26 September 2019: Curious what precaution means in terms of “what to do” re: climate. In the lower-stakes world of product development, precaution means reserving capacity for unknowns, sequencing unknowns before knowns, putting circuit breakers in place to cap time spent on a given effort, etc.
• 25 September 2019: Announcement coming soon.
• 25 September 2019: Underlying point: scale and complexity are opposed. We get scale by lowering complexity (factoring into isolated components, creating boundaries, enforcing standards). Example: This is why brand new product efforts start with tiny integrated teams.
• 25 September 2019: The highest praise I've gotten for Shape Up is people saying it makes them think harder. Much better outcome than adoption of a process.
• 25 September 2019: This is a deep one. Overlaps with modularity vs interdependence. To do more of the same, get more of the same. To do something new, integrate something different. https://twitter.com/yaneerbaryam/status/1176970390092095488?s=20
• 25 September 2019: It can also happen that one of those things is a great idea, but it's not ripe yet — not shaped enough. Suddenly you see how to do it and boom, it's exciting and top priority.
• 25 September 2019: When I catch myself trying to organize a bunch of things to maybe do next, it's a smell that probably none of these things are that great. Otherwise it wouldn't be a struggle to choose which thing to do.
• 25 September 2019: The amount of time spent grooming priorities is inversely proportional to how good your ideas are. As soon as you have a knockout idea it just shoots to the top and you don't care about anything else.
• 25 September 2019: Yes.
• 25 September 2019: Just updated Shape Up with a new section about new vs. existing products, settled vs. unsettled architecture, and R&D vs production mode. "First a word of warning about when shaping, betting, and building won’t work ..." https://basecamp.com/shapeup/4.1-appendix-02
• 23 September 2019: They’re not mutually exclusive. Think of it in terms of constraints. A haiku defines constraints but the set of possible haikus is still enormous. Or consider: “paint a dog” vs “a brown dog” vs “brown and facing left” vs “paint a small brush stroke directly at coords x, y”
• 23 September 2019: The book explains: https://basecamp.com/shapeup/1.1-chapter-02
• 23 September 2019: It’s “command and control” at one level of abstraction and total freedom at another. That’s the key point. There’s a difference between setting guard rails on what to do vs specifying all the details.
• 23 September 2019: I have been busy with the book and haven’t gotten back to product work yet. Let’s see. I’m expecting to a stick with hand-drawn sketches to set a clearer example but I’m not dogmatic about it.
• 23 September 2019: I learned that when teams tried to use them, the designers would take them too literally. Decided it was better to stick to handwritten examples. The key points are roughness and leaving enough latitude for creativity.
• 22 September 2019: Thanks! The team that builds (designer + programmers) is responsible for all aspects of quality. Programmers write their own tests. We have QA, but it's not a gate or a check-point. It's sugar on top to catch additional edge cases or small issues we wouldn't have found otherwise.
• 20 September 2019: The reference frames in @Numenta 's thousand-brains model remind me of Langacker's work on Cognitive Grammar. pic.twitter.com/ZJmUH9RX7h
• 20 September 2019: Excellent podcast with Jeff Hawkins about @numenta 's progress modeling intelligence. Especially the part about their new "thousand brains" theory and the role of nested reference frames in every cognitive act. https://lexfridman.com/jeff-hawkins/
• 20 September 2019: Yes the point about coupling is the key point. If you have a coherent design with macro boundaries in the code which you can see from project-planning altitude, then you can easily schedule two projects in parallel that won’t interfere for six weeks.
• 20 September 2019: Excellent. Hello to everyone in Boston and good luck with your talk!
• 20 September 2019: We’ve been doing this for 16 years. If your experience is different, that’s also fine.
• 20 September 2019: You avoid merge conflicts by working on unrelated things. This is easier to do when you’re small.
• 20 September 2019: Before today's AMA I chatted with Abadesi at Product Hunt about how to think differently about risk and how to separate strategic risk from execution risk. https://product-hunt-radio.simplecast.com/episodes/how-to-ship-work-that-matters-with-basecamps-ryan-singer-poLCy_bD?ref=podhunt pic.twitter.com/eOEsa1jf6K
• 20 September 2019: I mean to create contrast between HTML over the wire frameworks vs SPA frameworks. Going no-framework is something else.
• 20 September 2019: Rails/Laravel/etc isn't no-framework.
• 20 September 2019: Mostly likely including yours :)
• 20 September 2019: No it is about SPA vs HTML over the wire. SPA is a needless very expensive tax in most cases that prevents designers and programmers from working together more closely and slows down the feedback loop between them.
• 20 September 2019: Here's another example: maintaining feature flags. Small companies don't need to do this. It's not worth the overhead. Just don't merge to master until you want a customer to see it. We don't use them at Basecamp. Only massive companies with lots of parallel projects need them.
• 20 September 2019: This is part of a broader mistake. Small companies copy big companies. Big companies have different problems than small companies and pay extra costs to solve them. Small companies should copy what big companies did WHEN THEY WERE SMALL.
• 20 September 2019: Modularity is about gaining larger scale by giving up customization at a smaller scaler. Components only make sense if you literally re-use the exact same component all the time. Otherwise you pay the tax of modularity without reaping the reward. https://twitter.com/rjs/status/1175097948402634752?s=20
• 20 September 2019: ^ This also applies to working with unknown technology.
• 20 September 2019: On multi-disciplinary designers and the high tax of single-page-app tech like React. https://www.producthunt.com/makers/1-makers/discussion/2204-i-m-ryan-head-of-product-strategy-at-basecamp-and-author-of-shape-up-ask-me-anything#comment-880391 pic.twitter.com/OlM89QYTKR
• 20 September 2019: Does Shape Up apply to building a new product from scratch? It's a question of settled vs unsettled architecture. https://www.producthunt.com/makers/1-makers/discussion/2204-i-m-ryan-head-of-product-strategy-at-basecamp-and-author-of-shape-up-ask-me-anything#comment-880389 pic.twitter.com/mk33Az5HFb
• 20 September 2019: On the common problem where product people get squeezed with too many requests coming from sales https://www.producthunt.com/makers/1-makers/discussion/2204-i-m-ryan-head-of-product-strategy-at-basecamp-and-author-of-shape-up-ask-me-anything#comment-880377 pic.twitter.com/IaDkBDj9q8
• 20 September 2019: Just finished answering a big round of questions on this Product Hunt AMA: https://www.producthunt.com/makers/1-makers/discussion/2204-i-m-ryan-head-of-product-strategy-at-basecamp-and-author-of-shape-up-ask-me-anything
• 19 September 2019: (The theory is introduced in Chapter 5)
• 19 September 2019: @rhyolight You might like this book on IIT, Giulio Tononi's theory of consciousness. Lots of empirical data and quite rigorous. https://www.amazon.com/Sizing-Consciousness-objective-capacity-experience-ebook/dp/B07DFP5FK7/ref=pd_cp_351_2/134-0581134-9889002?_encoding=UTF8&pd_rd_i=B07DFP5FK7&pd_rd_r=3b3d9a35-e6de-4e49-bdf6-efb61cd04a2b&pd_rd_w=TuQRy&pd_rd_wg=uXZeE&pf_rd_p=ef4dc990-a9ca-4945-ae0b-f8d549198ed6&pf_rd_r=R7RKZX9FPV27J6DV3BYA&psc=1&refRID=R7RKZX9FPV27J6DV3BYA
• 18 September 2019: Tools are tools. You reach for them when you need them. There's so little time in a single day to get anything done. Better to be patchy and focus on one thing now, another thing later, according to what's timely and relevant.
• 17 September 2019: We avoid feature flags. You only need them if you are a super giant org with tons of parallel teams. Life is much simpler when master == what customers see.
• 17 September 2019: It's simpler then that. Sometimes we have a clear sense of the problem/opportunity and go do some shaping. Othertimes it's not clear what the actual problem is or what somebody means with a request. Then we can use JTBD methods as needed to clarify the requirements.
• 17 September 2019: Maggie had really great questions in this interview. We talked about who defines the work, how programmers and designers think differently, and how people working on product can better relate to their bosses. https://build.transistor.fm/33
• 17 September 2019: It would require a deep case study to see the dozens of unanswered questions that came up during the cycle and all the decisions the team had to make about how to solve them.
• 17 September 2019: Shape Up made an appearance in the Fall 2019 issue of the MIT Sloan Management Review https://shop.sloanreview.mit.edu/store/improving-the-rhythm-of-your-collaboration pic.twitter.com/E04sxskID4
• 17 September 2019: Production
• 17 September 2019: “How to make that happen” is much harder than it sounds. Plus we only specify a few key points of the solution. Tons of details and decisions can’t be specified up front and require creativity from the team.
• 17 September 2019: Yes, within the bounds of what was shaped. Like saying “go paint a picture of a dog.” There are constraints but still thousands of ways to satisfy.
• 17 September 2019: The key difference is defining the solution at the right level of abstraction. It’s not a spec that tells the team exactly what to do, neither is it so open-ended that you don’t know what you’re betting resources on. https://basecamp.com/shapeup/1.1-chapter-02
• 17 September 2019: It’s not mechanical execution. The solution is defined at the right level of abstraction. Leaves lots of room for problem solving. See https://basecamp.com/shapeup/1.1-chapter-02
• 17 September 2019: The team is responsible for the how. It’s a question of what level of abstraction you use when setting the boundaries of the solution. See https://basecamp.com/shapeup/1.1-chapter-02
• 13 September 2019: Would love to but I can’t make it on Sunday. Thanks for the invite.
• 9 September 2019: In Getting Real, we called this "epicenter design." Start in the Middle: https://basecamp.com/shapeup/3.2-chapter-10#start-in-the-middle pic.twitter.com/yub5sXXD7s
• 9 September 2019: Just updated Chapter 10: Get One Piece Done with new examples. This is how rough the first design can be. "First make it work, then make it beautiful." https://basecamp.com/shapeup/3.2-chapter-10#affordances-before-pixel-perfect-screens pic.twitter.com/GOEIvteAU7
• 9 September 2019: In case anyone else had this issue, it's fixed now. https://twitter.com/frenziedherring/status/1171080629179625472?s=20
• 9 September 2019: We just uploaded a new version that solves the issue. Thanks for letting us know.
• 7 September 2019: Nice phone-friendly infographic on this WSJ piece: https://www.wsj.com/articles/workers-are-fleeing-big-cities-for-small-onesand-taking-their-jobs-with-them-11567848600 pic.twitter.com/dko16yQbin
• 7 September 2019: I think an explicit model and the less deliberate pattern matching you’re calling a tacit model are so different structurally that I don’t want to lump them together with the same word. But we‘re probably looking at the same distinction there with different terms.
• 7 September 2019: A disagreement on Twitter? Impossible!
• 7 September 2019: A model that can’t be made explicit isn’t a model in any meaningful sense of the word. Pattern matching based on experience is not a model.
• 7 September 2019: Very individual. Seen both cases in super experienced people. Some people just love building. Others want to see a needle move. Sometimes both.
• 7 September 2019: Your gut is not a mental model.
• 7 September 2019: In my experience most craftspeople are more rewarded by the craft of the thing than the strategic outcome. With a healthy culture it’s not too much blood/sweat. At most six weeks at a healthy pace then you can do something else.
• 7 September 2019: Trial and error.
• 7 September 2019: Often overlooked by employees: the boss doesn’t need models or frameworks to make decisions. This is a feature, not a bug. It can’t be models all the way down. Has to bottom out somewhere. The ability to act without proof distinguishes entrepreneurs.
• 7 September 2019: “when coming up with potential work, what do we optimize for?” That’s the fundamental question of strategy. It doesn’t reduce to a formula.
• 7 September 2019: “Who clarifies the model by which betters bet?” In our case, the bets are made at the top. They don’t have to answer to anyone with a model.
• 7 September 2019: An idea is just the starting point for shaping. Would need to go further to set appetite, boundaries, define problem, outline solution, spot rabbit holes. After that work you have a potential bet. Whether they can do that depends on time, skill, and interest.
• 6 September 2019: It's structural. In many cases the work is coming down to the PM from somebody else and all they can do is try to manage it.
• 6 September 2019: Primarily the shapers. It requires dedicated time to do customer research and formulate a model of why some things are more important than others.
• 6 September 2019: I do. In theory they are different. In practice many product managers are actually doing project management.
• 6 September 2019: Case studies are coming in. Will share. Depends on your role and where you sit in the organization. If people above you aren’t ready, focus on how to deliver one project better and demonstrate results. Eg by shaping better or giving a team the whole project instead of tasks.
• 6 September 2019: See Shape Up for all the details. http://basecamp.com/shapeup
• 6 September 2019: 1. Shape work at the right level of abstraction: too vague (“build a calendar”) and team wanders, too concrete (a pixel perfect mock) and unknowns will bite them. 2. A hard deadline w/ no extensions. Incentivizes trade-offs. 3. Protected time. Leave them alone to work!
• 6 September 2019: No. Designer+programmer teams work in six-week cycles and self-manage within the cycle. In the two-week cool-down between cycles, senior management makes bets on what to do in the next cycle. That’s how we manage time and resources.
• 6 September 2019: We don’t have product managers. - Shapers define potential projects - Betters bet on projects (set priority, allocate resources) - Teams (designer + programmers) self-manage when building
• 6 September 2019: Traditional product managers sit between design, tech and biz without deep skill in any one. Mostly manage time/schedule. Shapers hold skills in design, tech, and biz. (Proportion varies.) Strong design or tech background. Trad PM manages work. Shapers generate work.
• 6 September 2019: Time to call this one: The term "MVP" does more harm than good. All the hard work is in defining "viable." When two people have different definitions of viable, the term has no meaning. Better to just shape the work, set clear expectations, and build to that.
• 5 September 2019: Why? Because GDP is an ensemble measure. It facilitates misattribution of properties from the whole (nations) to the parts (individual people). Rising GDP doesn't mean rising quality of life when the average is dominated by extreme values.
• 5 September 2019: A lovely idea. https://twitter.com/ole_b_peters/status/1168548609597616128?s=20
• 5 September 2019: Preferring "'it works, I just have to make it beautiful" shows respect for how hard it is to .. get .. something .. to .. work! Better to start there vs. lots of arbitrary visual design constraints that don't reflect the underlying interdependencies in the actual problem.
• 5 September 2019: One of our programmers, @flora_saramago : "When I think about the two scenarios of 'it works, I just have to make it beautiful' or 'it's beautiful, I just have to make it work' it's so clear in which situation I'd rather be in." (Hint: the former) https://twitter.com/rjs/status/1169725574962544642?s=20
• 5 September 2019: Overheard in a team’s Campfire today: “I just pushed an ugly version that works ... will probably still tweak the backend, but it's enough for you to experiment with the design” Music to my ears. The opposite of starting with pixel-perfect design. See: https://basecamp.com/shapeup/3.2-chapter-10#affordances-before-pixel-perfect-screens
• 4 September 2019: Sometimes I'll give in and put some complicated states in a form. But I really like how the breadboard pushes back at me and invites me to rethink the structure and seek something simpler.
• 4 September 2019: For example, "claim" may be too general for the place. Maybe there's a way to break it into steps or parts where each part of the interface has a single responsibility. In the spirit of how programmers do factoring.
• 4 September 2019: Probably too hard to talk about over Twitter... but I love thinking of disabled elements as a smell that the design is trying to do too many things. Then break it into separate processes or steps or alternate flows until they go away.
• 4 September 2019: But if you really want to update the same screen, then yes you can think of that part that updates as a component in the breadboard and replicate the place for each state. Annotate the name of the place with the state in each snapshot.
• 4 September 2019: Eg. instead of updating the current screen with "processing," take them to a screen that says "processing..." then take them somewhere else. Then you have distinctive places instead of states.
• 4 September 2019: Yeah you can do multiple snapshots of the same place over time. It's worth asking first if you can simplify by making those different states actual different places. Usually places are easier to reason about than states.
• 4 September 2019: The six week cycles are where we look for productivity. The two week cool-down allows us to sustain that. They prevent bugs and other random issues from intruding into the cycles and interfering with the productivity there.
• 21 August 2019: Thanks, audio version is in the works.
• 14 August 2019: Nice intro to @ole_b_peters' work and "the set of ideas now called ‘Ergodicity Economics’" ... "overturning a fundamental concept at the heart of economics." https://t.co/Vz2fUHDWXA
• 8 August 2019: @syedamaanullah Sign up here to find out when other formats are out: https://t.co/w9ZUwtcSjh
• 6 August 2019: You can sign up here to find out when we publish other formats: http://eepurl.com/gyZbC9
• 2 August 2019: Hearing from a lot of people that they realized their early designs were “too concrete” after reading Shape Up. Great to see leaders giving more room to their designers now.
• 31 July 2019: Notability or GoodNotes.
• 23 July 2019: "That's the fundamental question of product design: how do I create the fit between what I know [how to do] and what people need?" @VelocityWong interviewed me on the Rework Podcast about writing Shape Up and some of the big ideas inside. https://twitter.com/reworkpodcast/status/1153696066543468544?s=20
• 10 July 2019: We’ll get there.
• 10 July 2019: Great question. That would require another book to explore fully. For a short take, I'd recommend this video: https://demandthinking.com/episodes/2017/7/23/episode-1-think-you-might-be-building-the-wrong-thing-youve-misinterpreted-demand
• 9 July 2019: Here's a diagram to clarify that: https://basecamp.com/shapeup/4.2-appendix-03#six-week-cycles-two-tracks . The shaping happens in parallel to the six-week cycles. During cool-down, the teams are totally free. Gives them breathing room to deploy, fix bugs, learn something etc.
• 9 July 2019: ⭐️The book is live and you can read it online now! Shape Up: Stop Running in Circles and Ship Work that Matters https://basecamp.com/shapeup pic.twitter.com/z7HB9svC2S
• 3 July 2019: Jekyll templates designed by @AdamStddrd .
• 2 July 2019: Wrapping up the final chapters of the book, on how to make scope cuts and move on when it's time to ship. pic.twitter.com/bwEcmeQTTW
• 21 May 2019: I checked it out. Scrivener doesn’t do any versioning.
• 20 May 2019: @Paradosso @ScrivenerApp No mention of versioning anywhere on their site.
• 20 May 2019: Yes.
• 20 May 2019: Maybe writing apps don’t do this well because they model the data incorrectly. A draft under rewrite is not a single sequence of text. It’s a network of different pieces that are working or not working. pic.twitter.com/cdkwg8xKgO
• 20 May 2019: Writing software should help with: - I don’t like this paragraph. Let me try three different versions. - This chapter isn’t working. Let me reorder everything without losing what I have. - I have three different ideas for this sentence and I don’t know which one is best yet.
• 20 May 2019: When graphic designers work, they put dozens of different versions side by side on a canvas. Why don’t writing apps support this? No app I’ve seen lets you keep two alternate versions of a paragraph in play, or try out a whole new take on a chapter without losing the current one.
• 16 March 2019: @Aylon133 We usually mix it up, but sometimes the same group will work together on a team for a couple cycles in a row. It depends on expertise, what kind of work they've done recently, and availability ...
• 8 March 2019: @sassynerd13 Oh, thanks. Fixed those up.
• 4 March 2019: @SamuelHulick @jasonfried @chaseclemons I think it’s a valuable input to the process of shaping up projects to potentially do. But I’m skeptical about the value outside of that process.
• 2 February 2019: This will become “Getting Real 2.0.” Much deeper, more actionable, with 15 years experience behind it. All about how to do meaningful work and make meaningful progress on your software product. https://twitter.com/rjs/status/1091843806662705154?s=21
• 2 February 2019: Significant progress outlining the book on how we work. With help from @bmoesta and @chriscbs in Detroit. pic.twitter.com/DagMTfHjgP
• 8 January 2019: @ole_b_peters @RicardoJGMateus @normonics @DavidDeutschOxf /cc @bmoesta
• 2 November 2018: @jaybowles_ @NathanaelB Well-said: literate. Designers don't need to be able to do the back-end coding, but they should be able to follow the discussion about how the system works (or could work) in order to make trade-offs.
• 20 October 2018: Agree with these take-aways from Jeff Hawkins' talk on @Numenta's latest work: (https://t.co/XiepEck7KM) https://t.co/rco75EYgH5
• 3 October 2018: Unpacking a customer request for some kind of “out of office” status. See also: https://www.feltpresence.com/functions.html pic.twitter.com/VBwm4sYtYO
• 29 August 2018: RT @tobi: One of the ingredients in Shopify’s success has been to completely ignore academic credentials in hiring. It’s a signal but just…
• 25 August 2018: Depends if you're doing the same kind of project more or less for each client, or if you are building new concepts or features you've never done before.
• 24 August 2018: In other words there are unknowns and uncertainty but the risk is capped. We run 2-3 projects in parallel like this at a given time.
• 24 August 2018: We only budget one project at a time, never a series. No roadmap. We don’t budget a project unless we have a clear outline of the solution (there’s preparatory R&D). Those things roughly bound the unknowns which the team identifies and tracks on the hill within the budgeted time.
• 24 August 2018: Estimation requires knowing what you’re doing. That means you can estimate downhill but not uphill. You can, however, budget anywhere. That is, set a maximum amount of time you’re willing to spend. Budgeting != estimating.
• 24 August 2018: Real Work vs. Imaginary Work. On getting your hands dirty to validate an idea and catching problems earlier in the development process. https://m.signalvnoise.com/real-work-vs-imaginary-work-8bdb84a7d1da
• 28 July 2018: @SimonDeDeo @gboeing Salingaros. From the link and video above.
• 28 July 2018: @adalberacht Prototyped in OmniGraffle.
• 20 July 2018: From a design session today: “Yeah we can do that. Either way, it doesn’t change the circuitry of the idea.” Different open questions impact the design on different levels. Eg. a potential change to the wording versus a potential change to the steps in the flow.
• 18 July 2018: (Or they will bail and find another way to get it done, depending on the context. Still causal.)
• 18 July 2018: Not 100% about research. When you understand the context well enough, you can see the causality. Eg. somebody who is running out of time will get frustrated or anxious when it starts to take too long and there isn't an indication of how much longer it will take.
• 18 July 2018: In this example the rush comes from the surrounding situation (trying to get in to do something specific). This flow lives within a bigger context of what they are trying to do.
• 18 July 2018: The purple is neutral (being rushed isn't necessarily bad) and the red is negative.
• 17 July 2018: If you don't want to use Google, the alternative is to turn off phone verification. Per David's post, keeping it on, as-is, is actually less secure.
• 17 July 2018: Interviews work.
• 17 July 2018: Some feelings are caused by the UI and others are caused by the situation. If they are rushed because of the situation, you can't do anything about that. But knowing that, you could streamline the UI so it's faster and doesn't cause frustration in that situation.
• 17 July 2018: Yeah, announced here: https://m.signalvnoise.com/protect-your-basecamp-login-with-googles-two-factor-authentication-c7c495e49292
• 17 July 2018: Credit to @bmoesta for the ideas behind this.
• 17 July 2018: Note how experiences build on each other. Due to the situational context, they're already rushed at the start. That leads to frustration (seriously!?) and anxiety (will I be able to log in?). Later, being asked a question that's hard to answer builds up the frustration even more.
• 17 July 2018: You can't really "design" the UX per se. The UX is the reaction to the design. When the experience isn't right, you change the product to produce a different experience.
• 17 July 2018: The difference between UI and UX in one image. The key to understanding UX is to introduce time. Things like an increase in anxiety (wait, what?) or running out of time (this is taking too long!) happen at specific moments. pic.twitter.com/p0qhaTJF3K
• 16 July 2018: @normonics The “too much variety” case is interesting. I bet the way that manifests as a problem is very context sensitive. Been thinking about that w/ design. Eg. too much fidelity too early leads to time spent on details that are thrown away later.
• 11 July 2018: Yeah. It's the practitioner POV. Practitioners rarely teach in higher ed.
• 11 July 2018: Beware circular design requirements: “They want to create an account.” “Why?” “So they can get the audio recordings.” No, what is the situation such that now they will do work to get the audio? Separate the demand (struggle) from the supply (how the system works) and redesign.
• 11 July 2018: Of course you can design with vague goals and little context. You’ll just spend more time feeling lost and wandering around.
• 11 July 2018: You can’t design a route with just a destination. You need the starting point. So often the starting point is far too vague to actually plot: “they need project management” or “they do sales.” Need a specific moment when the status quo has to change.
• 11 July 2018: Replace “want” or “need” in a design conversation with “struggles with” and this will reconnect it with reality. Struggle is a context, a vector with two ends, not just a desired state.
• 11 July 2018: "When you just say the ideas they sound foolish, whereas if they’re dramatized one feels it." - Stanley Kubrick. What does it mean to dramatize an idea? It has a lot to do with introducing time, sequence and causality. Not a flat static thing in space. https://kottke.org/18/07/the-meaning-of-the-ending-of-2001-according-to-stanley-kubrick
• 11 July 2018: Yeah will share something more well-rounded about this soon.
• 10 July 2018: Of course it would be friendly. "Hello there. I saw your name and job title and thought you might be interested in this article. Would you have 12 minutes free this afternoon to take a look?"
• 10 July 2018: Product idea: a Gmail plugin for handling persistent salespeople. With one click it deletes their message and schedules a series of replies to them, maybe five replies over the next two weeks. Body of each reply is a random Wikipedia article. Fight fire with fire.
• 10 July 2018: Most design problems I work on have a central flow. What's an example of the type of thing you're thinking of?
• 10 July 2018: Applying "Position, Position, Position" ( https://m.signalvnoise.com/position-position-position-34b510a28ddc#.c52p6x2pl ) to breadboarding: pic.twitter.com/4ataJhOj1g
• 10 July 2018: Far more constrained than statecharts.
• 10 July 2018: Tools in the "thinking" quadrant need to be very fast with the right primitives always at hand. https://twitter.com/rjs/status/1011334353782280198
• 10 July 2018: Still struggling to create these quickly. Might have to just hand draw them. OmniGraffle is too slow and clunky. Whimsical's defaults are too constrained (no line separator, can't underline text). For delivery, you can spend a lot of time. For thinking, it needs to be FAST.
• 10 July 2018: There's a difference between a diagram for delivery and a diagram to enable conversation. Here's a breadboard flow suggesting some copywriting and sequencing. Like drawing on a whiteboard but remote and async. pic.twitter.com/LD9jhQICLf
• 9 July 2018: WIP, going to change those. == is a grouping mechanism. Don't need the — after all. Can just use space. Here it is in shorthand annotated with types: pic.twitter.com/Xwj2nI1kcI
• 9 July 2018: It's more constrained than an action diagram, with specific primitives, purpose and rules of construction. Closer in spirit to this: https://signalvnoise.com/posts/1926-a-shorthand-for-designing-ui-flows
• 9 July 2018: No I just happened to only have one arrow drawn in this case. The idea behind the breadboard is to focus on the components and the flows (paths the user goes through) to specify an interface idea without a wireframe.
• 9 July 2018: Borrowed from electrical engineering ( https://en.m.wikipedia.org/wiki/Breadboard ) to contrast with wireframing. Most UI design is too visual, too early and skims past the fundamentals: the flows, affordances, paths of action. https://mobile.twitter.com/rjs/status/1015298521145192449
• 9 July 2018: Experimenting w/ an updated UI shorthand for “breadboarding” (mapping out UI components and connections, without any visual decisions). One of those cases where the iPad feels like magic. First draw a sketch, then pull up the sketch in another app for reference. pic.twitter.com/w9jbn25fL6
• 9 July 2018: “In reductionist thinking, fitness is considered a property of the organism ... However, fitness is actually a property of an organism in a particular context.” Good POV for designers. Contextual fit, not “I like it, I don’t like it.” https://medium.com/complex-systems-channel/relational-properties-in-objective-science-d723ddb4fac4
• 29 June 2018: Yeah also think it'd be valuable to wireframe some components and not others. Would like to start with a graph of affordances and then selectively wireframe specific high-consequence spots when working out a concept. Leave the rest open to work out later.
• 29 June 2018: Yeah. That feels close. For UI I think the primitives should be a little different than states/transitions, which are too general. Better list might be: places, copy to read, affordances, and transitions. Early work on that here: https://twitter.com/rjs/status/1011109010492350464?s=21
• 29 June 2018: In supply/demand terms: The set of possible purposes is selected by designers (demand-side requirements). Those are implemented as a set of possible interactions (supply-side requirements). In the moment of use (a specific demand-side context) user selects one path in the supply.
• [29 June 2018](https://web.archive.org/web/2018072