How we developed a feature using Basecamp’s Shape Up
Let me start with saying — I’m a big fan of Basecamp. I’ve read most of their books and listened to Rework podcasts. I love their counter-intuitive way to solve complex problems to deliver great results.
We started reading Shape Up as the first book in our newly-created book club at ROI Hunter. When discussing the content, we noticed that the book addresses some of the pains we had in the product development. At one moment, I remember myself saying that I’d love to experience one iteration according to Shape Up.
And so I did. But before jumping right into the details, let me give you a little bit of context.
What ROI Hunter does
ROI Hunter enables e-commerce companies to connect product feed and integrate product-level data from Google Analytics, Facebook, Google ads, internal systems, and other e-commerce platforms. This data can be used to optimize campaigns for profitability, looking at factors like margin, the chance of a return, under-promotion, and over-promotion. Finally, dynamic data-driven ads can be created at scale using customizable templates, and videos can be generated from static images through our Creative Factory tool.
You see that there’s a lot we do and the variety of domain knowledge requires a lot of specialists. We’re a small team and sometimes we struggle with coordinating the time of people needed for the feature. Combining this with inaccurate estimates, we don’t always release on time. And as a designer you probably know that there are cases in which your design can get old before it’s taken to development. Luckily, this was rarely our case.
Where Shape Up comes in handy
Shape Up framework addresses these problems. Instead of never-ending sprints, there are strict six weeks dedicated to deliver the feature. A small team of one designer and two to three developers commits to deliver the feature. Another important difference is that there are no user stories but a pitch. The pitch serves as a comprehensive proposal for the project. It contains a problem and solution’s must-haves, nice-to-haves, and no-gos. The Product Manager can include fat marker sketches of the solution, but shouldn’t go into details of the UI. The team then has full ownership of the feature and it becomes their single focus for the next 6 weeks.
The “test” feature
The problem we wanted to solve was that our users didn’t have a clear overview of the performance of brands and categories they promote in the campaign. The solution was a panel providing an analysis of the selected campaign. The key components were graphs, a data table, and a filter to select categories or brands I want to see data for.
So how did our cycle go?
Week 1
Monday started pretty calmly since we were all just reading the pitch over and over again. When developers started preparing details for implementation, I quickly sketched the whole user flow to see the main interactions and screens. This helped us to identify the first slice to work on. According to Shape Up, the slice is a vital element of work that integrates front-end and back-end. After the team finishes one slice, it moves to another.
We identified graphs and the navigation as the first slice. I started sketching the low fidelity wireframes using Figma and we did ongoing validations with developers. Knowing what APIs are needed and where the user inputs are, was enough for them to start working. After the first week, we were pretty excited about how smooth the cooperation was and how much work we were able to finish.
Week 2
We set ourselves a goal to have a functional prototype by the end of the second week. No high fidelity, no filtering, just showing the data in the graphs and the table. When developers were working on the implementation, I could prepare usability testing with a goal to test the navigation on the panel. The testing didn’t uncover any major issues in the design, but I gathered a few ideas on how to expand the feature.
And we had the demo ready! It was so rewarding to see the feature functional. It wasn’t pretty, but already providing value only after two weeks of work.
Week 3
The next slice we moved to was the filter and here we hit the roadblock. In the pitch we weren’t sure how powerful the filtering should be and how detailed analysis our users need to do. We did a few iterations in Figma but quickly found out that we can’t move without any insights. This was a situation when the Product Manager who’s also the owner of the pitch stepped in. He advised us to look for a simple way how to solve the filters. This decision will allow us to expand the filters later when we gather more feedback.
Week 4
The fourth week was about finishing the core implementation of graphs and filters. In the meantime, I was finishing the high fidelity. We were styling the graphs and identifying the edge cases. I also prepared the error warnings so that everything could be ready for handing the feature over to testers.
Week 5
When we were done with the majority of the work, the team’s pace slowed down. We were polishing the last details of high fidelity and onboarded one of the testers to the project. We started discussing the details of the release and whitelisting first users for beta testing.
Week 6
During the last week of the cycle, we nearly fell into the a rabbit hole. A rabbit hole means a risk — any technical unknowns, design issues, or misunderstood interdependencies. The pitch mentioned that the data on the panel should be refreshed when selecting another campaign for analysis. In our implementation the user had to click on the button to see the data. We started looking for ways to implement this functionality but as the end of the cycle was approaching, our Head of Engineering stepped in and together we decided to stop there and keep the sixth week strictly for testing.
The final wrap-up call was full of positive emotions. We delivered successfully, and we enjoyed this way of work, the cooperation and the ownership of the solution. And what’s next? We had the calls scheduled with beta users to hear their feedback. And we’ll definitely run some more cycles of Shape up!
So did Shape Up work for us?
We liked the full focus on the feature without any interruptions. No need to switch the context between various tasks from different domains speeded up the whole development process.
Developers appreciated that they could collaborate on the design more than they were used to. Using Figma and its powerful comments enabled us to quickly iterate on various ways how to solve problems. Next to the pitch, Figma served as a source of truth how the feature should look like and work. For me it was rewarding to see the design implemented from scratch to working prototype just within a few days.
Any lessons learned?
We agreed that the success of the team depended heavily on the pitch. The output of the team is just as good as the pitch. Generally, the pitch should provide you strong creative boundaries to come up with the solution, but also give you enough freedom. We were regularly coming back to the pitch and validating its bits and pieces to see we’re on the right track.
Next time we’ll include the testers right from the beginning. The tester doesn’t have to be fully dedicated to the team but should be well aware of how the feature works. So he can test typical scenarios and provide feedback as relevant as possible.
It’s also crucial the designer is invited to shaping. He should collaborate with the Product Manager on how the feature fits to the current user experience. Or sometimes you like to do a competitors’ research before outlining the solution.
It turned out that following Shape Up, we can address some of the problems we have in the product development. We’re preparing two more stories, one written by the product manager and one by the developer. Stay tuned!
