Shape Up reflections: Volume 2
28 Nov 2020This post is a lightly edited version of an internal update I sent to everyone at CareerPlug after the completing our second product cycle, modeled on Basecamp’s Shape Up method. I am making these updates public in hopes that others will find value in the lessons learned from a real team adopting a fairly radical new product development process.
The first update includes more information about our product team and our company, for context. Italicized text are extra context I’ve added for the public version of this update.
Let’s dig in. -David
Team - Cycle 2 is in the books! This was our second cycle following our new product development process and our first with 6 weeks of cycle time instead of 4. We made great progress on some key initiatives this cycle and the team learned a lot of lessons to make future cycles more effective. We’ll keep learning as we go, but we should feel proud of the learning we’ve done in the first two cycles and the work we’ve produced.
Below you’ll find an overview of the things that worked well, the things that didn’t work, and our lessons learned for future cycles. At the end of this reflection, I’ll look at some of the work we released in the first cycle and review the results so far.*
What worked
Six weeks is a better cycle length Extending cycle length from four to six weeks gave us more time to build impactful features and more space to explore options and pivot when needed. The biggest changes in this cycle would not have been possible to build in four weeks.
Small changes and open design space can go a long way In Cycle 2 we released a number of small changes that didn’t add more mental overhead for our users but still made their experience with the product better. This is possible because of the work we’ve done to make the product more focused. Over time, the product will get less focused and become harder to reason about without concerted effort to keep things as simple and as relevant to the user’s goals as possible.
We’re adapting quickly and learning from mistakes This is still a very new process for the product org and for the company. We don’t expect it all to just work right away. As we encounter new issues or something unexpected goes wrong, we’re identifying the problem and implementing solutions so we’re better prepared for next time. This will continue being a theme for the next few cycles - getting a little better each time is the goal.
- An example of an in-cycle adjustment is that each project team now updates the status of their project with a red/yellow/green indicator so that we can identify off track projects and quickly review the status of all projects as needed. [David note: This small change was implemented as a new field in Jira, which engineering and QA use to track their in-cycle work. Hill charts would be more useful, but we haven’t adopted Basecamp as an organization.]
What didn’t work
Poorly written pitches A few pitches did not set the project team up for success. These were written by me and the miss on these was down to me not doing a good enough job in the shaping process.
- The pitch for new account onboarding included way too many ideas, far more than could be achieved in a single six-week cycle. That pitch should have been scoped down to focus on a single impactful, achievable outcome and the rest of the work should have been included in a future pitch
- The pitch for the new activation process needed to have the content of the page written and approved before the project began. Leaving marketing copy and pricing page layout copy out of the pitch made it difficult to build the right experience and led to way too much back and forth to agree on details that aren’t in the project team’s purview.
[David note: One of our major challenges has been finding the right level of detail to include in pitches. I left too many things open to interpretation in this past cycle and teams spent more time spinning their wheels than they should have. Finding the right balance is tough!]
Communication needs to be better Communication inside of the product org and to other teams was not as good as it should have been. This isn’t just a Shape Up challenge. Communicating clearly, thoughtfully, and in a timely manner is hard and we’re still learning how best to make it all tie together.
- Inside the product org, there were several instances when a project team got off track on a project and did not raise the flag to their manager or the pitch owner quickly enough. This delay led to misses that could have been avoided with faster, more effective communication
- Outside of the product org, several projects needed significant input or sign off from other teams and we did not communicate effectively with those teams, leading to delays in projects and missed requirements. [David note: Communication is hard and process is only part of the challenge. Our team is tight knit, kind, and supportive, but we also have some ingrained habits like not asking for help soon enough (because we don’t want to bother our peers who are busy) that will take a concerted effort to overcome. Shape Up isn’t a magic bullet and you’ve still got to do the work!]
Outcome tracking isn’t great Tracking outcomes is very manual and outcome definition is unclear. Since desired outcomes are just being tracked on the pitch, looking back at the work in a cycle and identifying how many projects achieved their desired outcome is difficult and time-consuming. This difficulty is compounded by the vague outcomes on some projects, particularly projects aimed at bringing in functionality to Voyager that exists in Classic but doesn’t have a clear business objective. /[David note: Voyager is the new version of our core software, Classic is the old version. We’ve migrated most of our user base to Voyager but the work to bring the rest of over has been difficult to fit into the Shape Up framework since the business value for some of these changes is quite low.]/
What we learned
Communication is (still) key If we write really clear product pitches, hand the pitch to the project team cleanly, and stay tightly connected to the pitch owner while we’re building, the work goes smoothly.
When we miss on one of those three key communication pieces, things get bumpy.
Pitches need more definition Through the first two cycles I intentionally left pitches open for more interpretation by the product teams. The reason for this is that our team, unlike the Basecamp team who created Shape Up, doesn’t have a huge amount of ingrained UX design experience on the selection committee. Instead of closing off the opportunities for our UX designers to do what they do best, I created pitches that left them room for research; however, I went too far in this direction and some of our pitches haven’t been clear enough to be really actionable and achievable in the appetite we’ve assigned.
In upcoming cycles we’ll need to find ways to include the UX team in the creation of pitches so that work is more clearly defined before it reaches the betting table or gets assigned to a project team.
What’s next
Cycle 3 is a holiday-shortened cycle. We’ve intentionally committed to less work in this cycle (no more than 4 weeks per project team) and we’re keeping the work more internally focused so that we can comfortably launch these changes when they’re ready even if we’re short staffed on the client-facing teams.
Cycle 1 early results
As mentioned above, outcome tracking is more manual than we would like right now, but we can identify the impact that some of the Cycle 1 launches have had so far: [David note: I removed the individual results here since they contain a lot of pretty confidential information about our client base. Each update was structured as a link to the project in our product management tool + a brief run down of the current state of the project vs. the expected outcome in the original pitch. In general, the work we released in our first cycle performed reasonably well, with a couple that underperformed expectations and a couple that exceeded expectations. Sharing outcomes internally has been very well received - our product organization’s results are harder to measure than other teams and the transparency into how our work is performing has helped build trust. Happy to share more details on the structure privately, for anyone interested.]