Makers
I'm Ryan, Head of Product Strategy at Basecamp and author of Shape Up. Ask me anything!
Hi Makers! I've worked on all levels of the software stack, from UI design to back-end programming to strategy. I've spent over 16 years at Basecamp and designed features used by millions and invented processes our teams use to design, develop and ship the right things. These days I'm focused on strategy: understanding what our customers are trying to do and how to make the product fit them better. My new book is called "Shape Up: Stop Running in Circles and Ship Work that Matters" it's all about how product development happens at Basecamp. I also talk about it in this week's episode of Product Hunt radio. I will be logging in to answer questions on Friday 20 September at 10:00am MT.
Posted in Makers
Comments
I'd love to hear about how you avoid getting into slumps with projects at Basecamp, specifically those kinds where as a team you continue tweaking and keep postponing the point where you share the new changes with the public.
@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.”
Does your work also involve marketing the product after a launch? As per my conversation with Jason, he told me that Basecamp never had any marketer and the onus befalls on each employee to market the product. So to reiterate, does your role and your team also strategize product marketing as well while developing a product strategy?
@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.
I have a totally bootstrapped side project of an iOS app that I want to get in the hands of users. I know in Rework you guys talked about gorilla marketing some. Ideas on how one could do this in such a competitive mobile app landscape? I have some ideas and sharing on social media seems to just get lost in the noise. Cheers!
@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.
Hey Ryan, glad to see you here. I read Shape Up a few weeks ago. And we are using some stuff from the book, specially that curved graph that shows progress. It's a great tool to give visibility. My question: How much do developers and designers have a say in the "Why" and "What" is going to be built? I now it's culture dependent, but I got the feeling from the book that Devs and Desginers are kinda left out from the product development process.
@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.
Hey Ryan! Stoked to have you here on PH! Like you mentioned, you've worked on all levels of the software stack, I'm intrigued to hear how you started out? Did you come from a design / programming background or something else? Second question, if there would be one piece of advice you could give to someone who wants to build a sustainable business like Basecamp has, what would it be?
@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.
Hi Ryan, what was the defining point of your career when you began to truly start believing in your abilities? What lead up to it?
@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.
Hi Ryan, thank you for doing this, Basecamp and everything the team stands for is a big inspiration! 1. Background of the question is to not fall into roadmap as a timeline, or feature factory and being able to reiterate on features/setting the tone and expectations internally How do you manage work with the sales department regarding that you guys apparently run on 6weeks sprints, not knowing what's happening after. Would assume sales would want to set expectations with clients/prospects of what is happening. What were other hurdles switching to that system. 2. Who decides when a feature is ready, who has ownership and how do you make sure the person actually has the final call (vs. assuming it's a M and s/he needs to apply CEO card or gets overruled by more senior PM)? 3. Which other product teams do you admire/where do you get your inspiration/peer exchange from?
@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.
@rjs Thanks! 2. Listened to your podcast recently. Do you have an example from a leadership proposal which is the stage before actual wireframes (forgot how you guys named it)? Guess that would give a nice example also when leading product ppl to not interfere too much and give autonomy - besides the actual mindset to give autonomy. If too sensitive, obviously I understand. Thanks again!
@rjs Makes sense it's in there. Thank you:)
@rjs duh, ja, makes sense that it's in there 🙈 thank you
Huge fan of Basecamp’s products and approach to product development, thanks for doing this! My question is about priorities for a seed round startup. Is it more important to chase goals like X users by Y date, or validated learning by way of increases in conversion & retention rates? Are they even mutually exclusive? In short, do you find there is generally a north star metric that should drive early stage product development? (I probably just need to read the book!)
@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.
I'm curious to know your biggest (maybe counter-intuitive) learning after building Basecamp for 16 years. 🤔
@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.
👋Hi Ryan, the more we talk about separated IC and Management tracks at the office, the more i begin to wonder what path i should be heading in. I am an IC at heart, and in a perfect world, i would be sharpening my skills, mentoring junior designers and still having a strong influence in the product. But i also have a desire to build out the design team, juggle the creative demands and resources of the rest of the company and have a more strategic role in the direction of the product. Is there a happy medium between the roles? Is there a way to still be creative with boots on the ground AND have a higher-level impact on design efficiency and organization without being a people-pusher?
@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.
How do you prioritise on what's to do next? What are your ideal day to day looks like now? Do you have a cheat sheet that you follow when it comes to product strategic decisions? Unrelated question but hey it's AMA;) Ever been to India? Thoughts about products build from India? Will definitely be reading the book:)
Hey, Ryan, I'm a longtime 37Signals fan. While reading Shape Up, I was wondering about a couple of things: Do you guys merge & deploy at the end of a 6-week cycle or you do this during the cycle and enable the feature in the end? Do you track if people use new features, and how do you know you have solved a problem? Can anyone have a pitch or they have to go through the leadership? After book release, do you see other companies adopt those patterns? What is their feedback?
@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.
Hi Ryan! Thanks a lot for your time :) How much of what you explain in "Shape Up" could be applied when building a product from scratch? Your book has heavily influenced our new way of working (our first transition cycle starts in 2 weeks actually).
@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.
I'd love to hear about how you avoid getting into slumps with projects at Basecamp
Hi @rjs 👋, thank you for writing 'Shape Up', great read! You're mentioning the different roles you've had in the product development process – all the way from UI design, to backend development and now you're working with strategy. Do you think it's important to be have a multi-disciplinary skill set – design, dev, management, strategy – to be a good fit for a small product team? How important is it for new hires at Basecamp to have cross-disciplinary skills that might not touch directly on the role they're applying for?
@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.
Hi Ryan, We have developed a similar kind of tool just like basecamp called due.work. I want you to ask your feedback on that. Please enlighten me with your experience. Regards
Hello Ryan, thanks for this AMA. My question is - how should a start-up, in the Management consulting industry acquire clients ? Thank You
Hi Ryan, big fan of Shape Up. What made you guys decide to share Shape Up as a site? Was that a decision to ship quickly, test in the wild and get feedback before creating physical versions? Or was there more to it?
@kingshuk_mukherjee1 Yes. Mostly it removed a lot of barriers to shipping. It didn’t have to be perfect, I didn’t have to find every typo, we didn’t need to figure out how to lay out the images in certain way for pages in a print book, etc. And we wanted it to be very shareable — something people could easily quote or refer other people to. I did get a lot of helpful feedback in the first few days—mostly about typos and things like that. Then as the emails and tweets came, I discovered what questions people had and what needed to be added. This is helping us get to a point where we are more confident about releasing the book in other formats that are less malleable, like Kindle or pint.
@rjs Thanks Ryan. Great book and I appreciate how much effort when into documenting your processes. I'm learning a ton.
Why there is no board view with columns in Basecamp?