<aside> 💡 It's worth noting Basecamp is a multi million dollar company which PMF and a very mature product with millions of users. They have a very polished set of principles and procedures with a highly skilled team. They also just one product with each time having full autonomy and further still they have time on their side.
We work on very early stage ideas, with a founders requirements to consider with speed typically being of the essence. Through reading the e-book i've found some of their suggestions, frameworks and principles extremely interesting, however i've also noticed they be very tricky to implement into our particular teams and way of working.
</aside>
Their typical team composition consist of one designer and two devs or one designer and one dev. They don't have a Product Management role.
Their decision makers on at Basecamp CEO (who has the last word on product), CTO, a senior programmer, and a product strategist (CEO).
Below is a great interview with Jason Fried founder and CEO of Basecamp and co-author of the e-book. He discusses how his frameworks and methodologies can work for smaller teams. He also mentions that they are already working on a revised version which will cover more about their processes and dig deeper in some chapters.
🚧 Missed this chapter out. No need to take any notes. Worth reading though.
When we shape (aka: scope) the work, we need to do it at the right level of abstraction: not too vague and not too concrete. Product managers often err on one of these two extremes.
This is something i'm sure the PM team have been guilty of in the past. Getting a hold of Figma and creating a high-fidelity wireframe for our designer thinking they will be impressed and hoping we have saved them time. The more i read this chapter the more i agree with Basecamps theory - When we go straight to wireframes or high-fidelity mockups, we define too much detail too early. This leaves designers no room for creativity.
On the other end of the spectrum, projects that are too vague don’t work either. When a project is defined in a few words, nobody knows what it means.
A mixture between low fidelity wireframes and plenty of context is usually enough to begin the scoping process with a designer.