Growing challenges
But as the company grew from a startup up to scale up, it became increasingly more difficult to get to the same pace of shipping new features as before. Not only was the cadence a problem, but it became almost impossible to meet deadlines. The teams were doing a lot of parallel work which resulted in a lot of cross-dependencies between different projects. Getting something out of the door has become a lot more difficult.
In our company, the product manager has a central role that ties all the dots together. They should be the voice of the customer toward product teams. As a by-product of our growth, however, the product manager role started to transform into a project manager role where the product manager was to handle all the moving parts.
Similar to cars, a product team is a complex machine that should be well-oiled. For the product manager, it sometimes felt like pumping gas into the machine and changing oil at the same time while the engine was still running.
Features took ages to be built. We never knew when one would be released. Commercial teams were desperately asking for updates to share with customers. Designers and engineers started to feel disconnected. They felt like mercenaries, not missionaries. They wanted to be part of the solution.
The product manager should fall in love with the problem, but definitely not with the solution. When I’m interviewing designers, it really saddens me to hear that one of the top reasons they want to leave their current work is because of their relationship with the product manager on the team. They typically say something like this:
“The product manager doesn’t come to us with problems, but with solutions. He only wants to make his design shiny and colorful.”
Leveraging group intelligence can do wonders for the business. My experience is that whenever I was in the same room (even a virtual one) with designers and engineers, wonderful ideas came to the world. And most of them were not mine.
So why Shape Up?
The introduction part of the Shape Up book is describing the challenges Basecamp was facing. Spoiler alert: they were matching the exact challenges that we had.
The core principle of Shape Up is that the time is fixed and the scope of work is variable. You can always add more functionality, polish design, or improve what is already there. When you have a deadline, you have to make tradeoffs. There is a specific appetite — the amount of time the team is allowed to spend on the project. And this time cannot be exceeded. It means that within a fixed amount of time, you get a functional piece that you can get in front of the eyes of customers, get their feedback, and iterate the solution.
Moreover, designers and engineers form an autonomous team that has full responsibility to make their own decisions. Product managers can then spend more time shaping. A shaped project then gives clear boundaries to the team which can be more autonomous. It’s a circle.
Lovely.
How does Shape Up work in a nutshell?
Shape Up workflow has three core parts:
Shaping
Shaping is about finding the right level of abstraction to describe the project. Too concrete and you kill the team’s creativity as well as their engagement when delivering the project. Too vague and you risk nobody understanding what it means.
The shaped project forms a pitch — a document that explains the functionality from the user’s perspective combined with technical possibilities and business goals. It defines what the feature does, how it works, and where it fits into existing flows.
The pitch should include five elements:
Problem — What customer pain we try to address.
Appetite — How much time we want to spend on developing the solution.
Solution — The core pieces we have figured out during our research, presented in an easy-to-digest form.
Rabbit holes — It’s worth calling out some tricky pieces of the solution that may cause headaches for the team developing the solution.
No-gos — The appetite is fixed. We can’t endlessly keep prolonging the cycle time. That’s the crucial element of Shape Up. It’s therefore beneficial to set strict boundaries for the team for where to stop. You’re basically saying that the solution shouldn't cover this specific functionality.
Betting
Et voilà. We have a pitch. What to do with it now? There’s a high chance that this is not the only priority project in the company. And your project (pitch) will be competing for resources with other projects (pitches). So how to go about it? Before each six-week cycle, stakeholders hold a betting table where they decide what to do in the next cycle. At the betting table, they only compare pitches from the last six weeks. There’s no backlog. The book states:
“Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.”
Building
When the company settles on which pitches they want to go with for the next cycle, the team is formed around each of the projects (pitches). The team then has 100% focus solely on the project at hand and is expected to deliver the must-haves within a specified time. Easy :)
How we experimented with Shape Up
Now that we understand the key principles, let’s take a look at how we used them in our environment. Let me set the scene by explaining a little bit about what we do. ROI Hunter is a MarTech SaaS platform used by e-commerce companies for campaign management on Facebook and Google. Our core key value proposition is integrating 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.
The problem
As cool as it may sound, we’re talking about large data sets which can be very hard to comprehend and therefore not very actionable. This was a problem our customers faced and which we wanted to solve. We’ve spent hours and hours on calls with customers trying to decompose the problem into smaller parts. There’s a high chance that this is not the only priority project in the company. And your project (pitch) will be competing for resources with other projects (pitches). We identified some key data views which tied to our customer’s business goals. Before we wrote a line of code, we created a prototype of the report in Google Data Studio to go back to our customers and quickly gather initial feedback. This helped us very quickly figure out key elements of the solution. Our customers wanted to be able to easily see which categories or brands are being promoted by what campaigns, ad sets, and ads.
The appetite
We traditionally work with two-week sprints, but we knew that it wasn’t enough time to develop a meaningful solution. Given our non-existent experience with Shape Up, we decided to “play by the book” and go with a six-week cycle.
The solution
Thanks to the prototype in Google Data Studio, I knew that our core user persona (ad buyer) wants to view which campaigns sell what product categories and brands. There were three important views customers were using in the prototype: cross-sectional chart, time-series chart, and a table.
I also understood that to make this new functionality actionable, we needed to bring it as close to our current users’ flow as possible. ROI Hunter has a separate part of the platform called Facebook Insights. It allows ad buyers to manage and optimize their advertising on Facebook.
Facebook Insights inside ROI Hunter
I started with a very broad description of how interactions between Facebook Insights and the new product data report should behave:
- The user can select one or more campaigns.
- When finished with the selection, they open the product data report. As this is not a mandatory part of their workflow, they should be able to open the report only when they need it.
- They can select between brand and category view, filter specific values within the view, and modify the date range for which they want to see the data.
In the original pitch, I stuck with text description only. I didn’t use the breadboarding technique, but if I did, it would look something like this.
Breadboard sketch: opening product data report within Facebook Insights
I then switched to whiteboard using fat marker sketches. Originally, I created a couple of different ideas which I shared with the rest of the team. We settled on a panel-like experience that interconnects with our existing campaign management part of the platform. Now we had a rough idea of what the solution should look like. I then used my mad Photoshop skills to put together a fat-marker sketch we used for ideation with a print screen from a platform. Heavy-duty indeed. The result was the beautiful image below.
Fat marker sketch: panel opened within Facebook Insights
Since this was my first-ever experience with Shape Up, the hardest part for me was to stop at the right level of detail to grasp key elements of the experience, while leaving enough creative space for the Shape Up team (1 designer, 3 developers). What really helped me was to involve the designer right from the beginning to help me find the sweet spot (concrete/abstract). We agreed that this was the right level of detail that she needed.
Rabbit holes & No-gos
What is important to understand is that you will never get a full list of rabbit holes & no-gos on your own. By gradually sharing the pitch with more and more people, we were able to add more and more items to the list. It was an extremely important part of the shaping process that helped us set the Shape Up team up for success.
For example, one of the rabbit holes we pointed out was combining the campaign data and product data in the same view. Though at first glance the data may look similar, it is very different. We knew that explaining the differences would complicate the solution, so we decided to keep the data separated.
As I already mentioned earlier, no-gos draw a clear line that the Shape Up team should not cross. In our case, we knew that for some campaign types, it’s not technically possible to get complete data. How should we deal with it? Rather than sacrificing user experience with incomplete data, we agreed that the panel wouldn't support such campaign types.
Part of the Shape Up philosophy is to admit that you are working with a lot of unknowns, and you will figure out a lot of things on the go. This is going to happen regardless of how descriptive the pitch is. In our case, we tried to leverage our collective intelligence to be able to spot the biggest roadblocks before the team actually launches the cycle. We didn’t capture all of them. It was never our intention to do so. It’s the Shape Up team’s core competence to figure out the rest on their own.
Betting
There was no betting in this case. We only had one pitch. However, I am very excited about the concept. I feel that it could help us make the decision-making process of what gets and doesn’t get built a lot more transparent.
Being a B2B company that partners with rather big businesses, we have multiple stakeholders ranging from CEO, to sales, to customer support, which all want to have strong visibility and a share of voice in the betting, aka prioritization, process.
I am a romantic person, a dreamer, and a believer. And I believe that if we give people rules of the game, they will play by them and that it actually makes the game more fun for everyone. I believe that the “betting table” approach could potentially limit clashes between different teams over priorities. If we put every pitch “on the same betting table,” we make sure that all voices are heard and that we can compare each of the pitches against the rest. During betting, you need to have all data and arguments ready to back the decision of why the company should invest its resources to build the feature. In my humble opinion, this is a nice forcing function to reduce the HiPPO effect.
Highest Paid Person’s Opinion, colored
Building
We first needed to form the Shape Up team. There was one designer, two developers, and we also added our head of engineering, David, to the team. This was to make sure that we increased our chances of a first successful cycle. My role on the team was limited to ad hoc consultations when the team felt stuck, but that happened only once or twice during the whole six-week cycle. The team decided not to have daily standup meetings, but switched to sharing updates over a Slack channel. It made it very easy for me to be in the loop of what was happening and keep track of progress. We also had weekly wrap-up meetings, which were reserved times for demos and retrospectives.
If you’re interested in learning more about the building part of the Shape Up cycle, my colleagues, Martina and Vaclav, shared their experience from a designer and developer’s standpoint.
To shape up or not to shape up?
That is the question. And the answer for us is definitely to shape up more. The first experiment ended well. The team managed to deliver on time, and we received great feedback both from the team itself and internally, as it was already addressing some of our biggest challenges mentioned earlier.
It was a success as well for me personally. Shape Up gave my work a good rhythm. I was able to zoom out and felt more focused. I was honestly surprised to see how immediate the effect was. Having clear boundaries, the team self-organized itself and delivered the solution on their own. I used the time saved on shaping the next pitch. I simply fell in love with Shape Up.
The next stage for us is to multiply the number of shaped pitches to be able to have more autonomous and successful Shape Up teams.
It is important to mention that we don’t actually expect the whole company to fully switch over to Shape Up. There are two main reasons:
- Different parts of the platform use different technologies, which require certain expertise.
- Our business is strongly dependent on third parties (Facebook, Google), and they like to change things. We need people that can quickly react to unexpected situations.
