© 2020 ROI Hunter
Originally published on Medium on July 29, 2021
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 product development. In one particular moment, I remember myself saying that I would 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.
ROI Hunter enables e-commerce companies to connect their 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 optimise 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 customisable templates, and videos can be generated from static images through our “Creative Factory” tool.
You see that there is 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 everyone’s time needed for the feature. Combining this with inaccurate estimates, we do not always release on time. And as a designer, you probably know that there are some cases where your design might get old before it is taken to development. Luckily, this was rarely our case.
Shape Up framework addresses these problems. Instead of never-ending sprints, there are six weeks dedicated to deliver the feature. A small team of one designer and two to three developers commit 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 should not go into details of the UI. The team then has full ownership of the feature, and it becomes their single focus for the next six weeks.
Phases of Work according to Shape Up. Photo: https://basecamp.com/shapeup/webbook
The problem we wanted to solve was that our users did not 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 wanted to see data for.
A fat marker sketch of the panel.
Monday started pretty calmly since we were all just reading the pitch over and over again. When the 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.
The basic user flow helped us to identify the first slice.
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.
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 then we had the demo ready! It was so rewarding to see the feature functional. It was not pretty, but it was already providing value after only two weeks of work.
Low fidelity demo of the feature with live data.
The next slice we moved to was the filter, and this is where we hit a roadblock. In the pitch we were not sure how powerful the filtering should be and how detailed of an analysis our users need to do. We did a few iterations in Figma, but quickly found that we cannot move without any insights. This was a situation when the product manager, who is also the owner of the pitch, stepped in. He advised us to look for a simple way to solve the filters, because this decision would allow us to expand the filters later, once we gathered more feedback.
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.
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.
During the last week of the cycle, we nearly fell into 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. 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 successfully delivered, and we enjoyed this way of work, the cooperation, and the ownership of the solution. What happened next? We had the calls scheduled with beta users to hear their feedback, and we will definitely run some more cycles of Shape up!
We liked the full focus on the feature without any interruptions. There was no need to switch the context between various tasks from different domains, which sped up the whole development process.
Developers appreciated that they could collaborate on the design more than they were used to. Figma and its powerful comments enabled us to quickly iterate on various ways to solve problems. Next to the pitch, Figma served as a source of truth about how the feature should look and work. For me, it was rewarding to see the design implemented from scratch to working prototype just within a few days.
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 strong creative boundaries to come up with the solution, but also give you enough freedom to work with. We were regularly coming back to the pitch and validating its bits and pieces to see we were on the right track.
Next time we will include the testers right from the beginning. The tester does not have to be fully dedicated to the team, but should be aware of how the feature works so they can test typical scenarios and provide relevant feedback.
It is also crucial that the designer is invited to shaping. They should collaborate with the product manager on how the feature fits to the current user experience. They can also research competitors before outlining the solution.
It turned out that following Shape Up, we were able to address some of the problems we have in product development. We are preparing two more stories, one written by the product manager and one by the developer. Stay tuned!