I'm Ryan, Head of Product Strategy at Basecamp and author of Shape Up. Ask me anything!

@rrhoover Trust and good relationships between people are more important than anything else.

@rrhoover Another thing that keeps surprising me... I still find myself in situations where I'll be deliberating about how to go about doing a project and then Jason will say "just do something and let's see it in a few days." That pressure to just go DO SOMETHING is so important. Get out of the analysis and get into action with a short timeframe.

@cesc_vilanova Good question. There is a time when shaping the work and handing it off to a team *doesn’t* work. That’s when you are working on an entirely new platform or technology when the architecture isn’t settled yet. When the basic architecture isn’t in place, you find yourself needing to scrap everything and start over sometimes. There are lots of false starts. However you eventually reach a point where the main points of the design and the technical architecture are fixed, and *then* it becomes people to say “aha if I gave this to a different team to do, there’s firm ground for them to build on top of. I think they will succeed.” So the first step is to identify where you are. If you’re doing something entirely new and the architecture isn’t established at all, then it’s better to first bet some exploratory time. Set an appetite for X weeks to explore a handful of key features. Do the opposite of what the books says — don’t build them to completion, build them just enough to validate that the architecture works. The Pragmatic Programmers call this firing “tracer bullets.” Mix shaping and building together in one blurry soup during the allotted time and make the same people responsible for both. Then once the architecture is settled, you can flip from “research” mode to “production” mode. Then all the practices from Shape Up apply in full. You can confidently shape projects and make bets on them because you know the ground is solid and you won’t have to scrap everything halfway through.

@de I started making using interfaces using non-programming tools when I was a kid, like HyperCard, ClarisWorks and Microsoft Access. These tools let you have data in some kind of database in one place and then visually design “views” of that data and forms to input data. I think this is a great starting point for learning UI because it lets you experience the relation between front end and backend without a lot of hurdles. Then in the 90s as the web surfaced I learned HTML/CSS and started building interfaces that way. I was comfortable mucking around in Unix and stuff like that but wasn’t doing real programming yet. I tried to learn programming but didn’t get anywhere until Rails came out. Rails allowed me to connect the dots because the views are mostly just HTML/CSS with a little bit of code sprinkled in here and there. From there I worked down the stack to figure out what controllers and models are and eventually became comfortable programming. I don’t know how to build a sustainable business. There are so many skills that have to come together: from understanding the demand to decide what to do strategically, to having the technical ability to actually make something, to having the right network to reach people who might potentially buy it, and so on. I think the important thing is to start where your strength and inspiration are and then fill in around that as best you can.

@rstankov Yes each team works on a separate branch and merges/deploys at the end of the cycle. We don’t use feature flags. Feature flags only make sense in massive companies. Most product companies are better off keeping master sacred and only pushing code to master that is intended for customers to see. We do sometimes track the use of new features but we don’t dedicate a lot of resources to that. Sometimes we don’t care about data. We know we wanted to make a change and we make it and we’re happy afterwards. Other times we are too busy and our data person is looking into other things, for example maybe digging deeper into some conversion questions instead of feature usage. And then sometimes yes, we have a strategic question and aren’t sure how to make a trade-off so then we dig into some data for context. It’s very contextual. At one point we tried encouraging anyone to pitch. What we learned was that pitching takes time, work, and practice. It’s not very practical to ask everyone in the company to pitch when it requires bringing to together strategic understanding, design ideas, and technical literacy. At our current size it’s more practical for a few people to specialize in pitching. But that doesn’t mean we aren’t interesting in what other people in the company want to do. Conversations with other departments and people in the company are an *input* to our own shaping process. Anyone in the company can raise a finger and point out an issue that then becomes the seed of an idea and gets shaped into a project in the future. Yes, I’m getting lots of feedback from companies who are applying Shape Up now. The main feedback is that it’s given them a language for things they might have known or felt but didn’t have a way to articulate previously. The exact way they adopt it and which practices comes first depend on the role of the person who’s championing the change and how the existing org is structured. Seeing lots of successes so far.

@pwnklr 1. This question about sales is difficult. It depends on the top leadership at the company and what their priorities are. If the leadership wants to prioritize the best product, and to sell by having a better mousetrap, then they can tell salespeople to say “no” to feature requests and sell on the merits of what is already built. On the other hand if the leadership is chasing numbers and just sees design and engineering as a cost center, then they will prioritize saying “yes” to every lead and trying to make more sales. This is cultural. Both are valid. The point is to look hard at what leadership wants and how they make this decision and then decide if you are in the right place or not. You can’t change one model to the other. 2. Basically the team (designer + 2 programmers) is empowered to make all the calls and decide to ship what they built in the cycle. But it’s not black and white. There are cases where someone senior catches a major issue or calls out something that should change before releasing it. But our leadership (Jason and David) are intentional about using a light touch and giving as much autonomy as possible. The important thing is we don’t have any formal “gates” set up where someone has to pass a check before they can proceed to the next step. We don’t have gates for QA, code review, or product review. Just an informal back and forth as work is ready, sometimes doing a close review and getting input, sometimes not, at different stages, according to who’s around and what’s happening and what’s natural in the circumstances. At our current size (~ a dozen working on product) this is still possible and we don’t plan to grow headcount much more than that. 3. I’ve learned a ton from Bob Moesta and Chris Spiek, two of the main people behind the “jobs to be done” toolset for interviewing customers and defining problems and opportunities from the demand point of view.

@pwnklr See here in the book: https://basecamp.com/shapeup/1.5...

@rjs Makes sense it's in there. Thank you:)

@rjs duh, ja, makes sense that it's in there 🙈 thank you

@abadesi Thanks for organizing. I enjoyed it.

@abadesi First, we bet a fixed amount of time on a project. If we give a team six weeks to build a project, that’s it. By default, we don’t grant an extension. (This is called the “circuit breaker” in the book). It means that the team has to make trade-offs in order to finish on time. You can’t get stuck in a slump when you have a deadline :) Second, how to actually make those trade-offs ... chapter 13 in the book is about this. It’s called Decide When to Stop. The biggest thing is change the mindset from looking up at how much better you think it could be and instead look down at what people are doing today *without* the change you are about to ship. Compare it to the “baseline” — what people already have — instead of an ideal that you haven’t reached yet. Then you can say “ok I still think this that and the other thing isn’t perfect but, yes it’s much better than what people have today so let’s ship it.”

@allenfuller The north star should be requirements that come from understanding the context and desired outcome that your potential customers are in. That’s the real metric. What circumstance are they in where they need your product, what does progress look like to them, and how does this translate into design requirements. Then you know what to do to make something that’s valuable. The rest is secondary.

@simon_lind First, if your designers can’t code their own views (eg HTML/CSS for web apps) you’ll pay a very big tax. There are also tech decisions to make that affect this. If you choose a single page app approach like React, you’ll pay another tax because designers can’t directly contribute HTML/CSS. It all has to get converted into component code. In the majority of cases this isn’t worth it. It’s better to go with an HTML over the wire approach like Rails. This is especially true for small teams. A component approach makes sense for a huge company where modularity gives you scale. At a small company it’s a disadvantage, not an advantage. This also applies to how you think about mobile apps. Our mobile apps are 90% web views, glued together to native components with some special tricks. It’s an order of magnitude difference in the cross collaboration between design and programming because you remove this big barrier of coding the UI into native views. The shaping role is intrinsically cross-discipline. Shaping is bringing strategy, design, and tech literacy together to come up with the outlines of a concept worth betting on. One discipline that’s often overlooked is writing skill. We always prefer people who are the better writers when hiring because we do so much asynchronous communication.

@thedreamydryad I still have all kinds of doubts. They just don’t matter. It’s more fun to do things because you enjoy them and find them interesting and look for some way that they can be of use to other people.

@thechanch At Basecamp we dissolve this separation between independent contributor and manager with what we call “moonlight managers.” All managers have to do Real Work — make something. Then some percentage of their time is spent on managing other people, not all their time. This keeps everybody on the ground and connected with the realities of the work.

@gabriel_werlich When we shape work, we set the *boundaries* of the solution. Basically what the solution is, what’s in and what’s out. That eliminates lots of risk and uncertainty by fencing in the project. You can think of the shape of the project like guard rails. There is still the space *inside* that boundary. Hundreds and hundreds of decisions that need to be made. Lots of latitude to change the concept or solve things that were intentionally left unsolved at the shaping step. It’s like zooming in on the project from a great altitude. From very far away, you see the big outlines but not the actual details. Then as you get closer there are tons of things you couldn’t see before that now need to be solved.

@berkshop I don’t think there’s a formula. I would start on the ground in real life with people you know who need this thing and work out from there.

@yash_vardhan1 In our earlier years we considered the product itself to be our best marketing. If we made the product better, and treated customers really well, then they would tell other people and it would spread. This happened and worked really well for us for many years. I’m guessing Jason’s comment referred to that. At the same time, there’s a limit to how many people you can reach organically and through word of mouth. So recently after over 15 years we decided to also do some more purposeful marketing aimed at generating more awareness and reaching people we haven’t reached before. That’s being done by a separate small team independent of the product work.