Finished the book in January 2021. I recommend this book 9/10.
This is a great book if you deal with project management, especially if your team works with software design.
Ryan Singer works at Basecamp, a project management software company that has published a few books on working differently.
The books: Rework, Remote, and It doesn't have to be crazy at work all come out of Basecamp's leader Jason Fried and DTH. I recommend all three.
You can get your copy here.
My thoughts and notes:
P27-Steps to shaping:
Set boundaries: First, we figure out how much time the raw idea is worth and how to define the problem. This gives us the basic boundaries to shape into.
Roughout the elements: Then comes the creative work of sketching a solution. We do this at a higher level of abstraction than wireframes in order to move fast and explore a wide enough range of possibilities. The output of this step is an idea that solves the problem within the appetite but without all the fine details worked out.
Address risks and rabbit holes: Once we think we have a solution, we take a hard look at it to find holes or unanswered questions that could trip up the team. We amend the solution, cut things out of it, or specify details at certain tricky spots to prevent the team from getting stuck or wasting time.
Write the pitch: Once we think we've shaped it enough to potentially bet on, we package it with a formal write-up called a pitch. The pitch summarizes the problem, constraints, solution, rabbit holes, and limitations. The pitch goes to the betting table for consideration. If the project gets chosen, the pitch can be re-used at the kick-off to explain the project to the team.
P34-Make sure you have a clear plan for the "2.0" Don't just say that you are going to improve "Files 2.0" Make sure you are specific: "Better file preview","Custom folder colors."
P47- Don't operate as a conveyor belt. You will scope out a project, create ideas and markups. Finding the elements doesn't mean that the project should start; make sure you have a buy-in session and everyone agrees on the value before becoming actionable.
P56-Make sure you have figured out what your solution, your patches for potential rabbit holes, and the fences around the areas that have been declared out of bounce are defined. Then you need to write the "Pitch."
P58- Five ingredients to a pitch:
Problem - The raw idea, a use case, or something we've seen that motivates us to work on this.
Appetite - How much time we want to spend and how that constrains the solution.
Solution - The core elements we came up with, presented in a form that's easy for people to immediately understand.
Rabbit holes - Details about the solution worth calling out to avoid problems.
No-goes - Anything specifically excluded from the concept: functionality or use cases we intentionally aren't covering to fit the appetite or make the problem tractable.
P74- It's easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles.
P79- It's not really a bet if we say we're dedicated six weeks bit then allow the team to get pulled away to work on something else. When you make a bet, you honor it.
P80- You lose the momentum they built up, and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week.
P82- Use cool-down. Ask any programmer if there are things they wish they could go back and fix, and they'll have a list to show you. The cool-down period between cycles gives them time to do exactly that. Six weeks is not long to wait for the majority of bugs, and two weeks every six weeks actually adds up to a lot of time for fixing them.
P85- R&D Modes. Not everything can have a plan, pitch, and then release to the customer. Sometimes you have to dedicate a cycle to "try" to create something, to realize if it's useful. Just make sure that a timeline has been established.
P90- Questions to ask:
Does the problem matter? Is this going to help the customer or Autodesk?
Is the appetite right? Are key stakeholders interested in solving this problem?
Is the solution attractive? We have defined a problem, we want to solve it, but the solution is not great—then maybe we should wait.
Is this the right time? Projects should follow somewhat in line.
Are the right people available? Make sure you have the right people, or the project will struggle.
P93- Example of kick-off message from Jason Fried:
"It's next cycle time! First, this is a short cycle. We've got a few major holidays this cycle, plus the end of the year. People are busy with life, travel, snow (!), and all the other stiff that foes with ramping down one year and starting another. So with that in mind, we're going to do something a bit different this cycle...
P101- When you delegate a project downward to your team, they deserve some time to digest and think through the project. Generally speaking, if silence doesn't start to break after three days, that's a reasonable time to step in and see what's going on.
P111- Don't create task lists for each individual person on the team; create task lists based on the structure of the project. That way, the organizer can easily see which areas are done and which areas have outstanding work.
P116- Illustrate the project by using a mind-map style for visual, and then create To-dos below to structure the action needed.
P117- Good re-read: Case study on messaging the draft.
P129- Hill charts are one of the best ways to show progress on projects. I created one with Fusion 360 and PowerPoint.
P140- Journalists have a concept called the "inverted pyramid." The idea is their articles start with the most essential information at the top; then they add details and background information in decreasing order of importance. This allows print newspaper designers to get the crucial part of the story on the front page and cut the end as needed without losing anything essential. Effective teams sequence their problem-solving in the same way.
P143- It's less about us and more about value for the customer. It's the difference between "never good enough" and "better than what they have now." We can say, "Okay, this isn't perfect, but it definitely works, and customers will feel like this is a big improvement for them."
P146- As we come up with things to fix, add, improve, or redesign during a project, we ask ourselves:
Is this a "must-have" for the new feature?
Could we ship without this?
What happens if we don't do this?
Is this a new problem or a pre-existing one that customers already live with?
How likely is this case or condition to occur?
When this case occurs, which customers see it? Is it core-used by everyone-or more of an edge case?
What's the actual impact of this case or condition in the event it does happen?
When something doesn't work well for a particular use case, how aligned is that use case without the intended audience?
The fixed deadline motivates us to ask these questions. Variable scope enables us to act on them. By chiseling and hammering the scope down, we stay focused on just the things we need to do to ship something effective that we can be proud of at the end of the time box.
Comments