Several years back I was attending a kickoff meeting for Tonal’s live workout feature. The meeting’s goal was to develop the product vision. The project itself had already been greenlit and we needed to decide what we were going to build. The meeting included several members of the engineering, product, design and studio teams. The topics were wide ranging from the look of the workouts, to how users would see and interact with each other. It was a good product brain storming session with a ton of great ideas. At the end of the meeting, however, there were still a lot of disagreements about the vision and features and we were scheduled to meet again the following week.

Later that day, I had a meeting with one of the product managers and I told him I’d be making a bunch of tickets for the next sprint that was starting before the follow-up meeting. He said “You need to wait, we didn’t finalize any of the product decisions.” I disagreed, “You remember the first five minutes of the meeting where we said we’re going to stream live workouts from the studio and then never talked about it again? That’s months of work and we need to start right now if we’re going to hit our deadline.” I went on to explain that we needed to build the live-streaming since our current technology was built around recordings. There was also the expectation every feature of a workout to work similarly to our recorded content even though we won’t know ahead of time when to trigger the features. There’s a conference video about how Tonal’s recorded video interacts with the UI and machine feedback here if you’re curious. The expectation was so ingrained that everything we were doing in a recorded video would “just work,” that it wasn’t even discussed in the kick-off, even though all the studio processes and delivery mechanisms were completely different. I probably could have derailed that meeting by saying we had to completely rethink the workout experience, but I had already decided engineering should try to make everything “just work” and only bring it up if we couldn’t make a feature work live.

I managed to get moving on those items and we had MVP live workout capabilities in about two months. We had to figure out a new way to trigger in-workout functionality and deliver it at scale. We had to create custom tools for the studio that would include rundowns of all the events that were planned during the workout and be able to trigger those and insert markers in the live-stream. This system also needed to control the in-studio functions like the coach’s Tonal and the teleprompter. All the live player functionality needed to be added to our frontend application as well. We integrated Amazon IVS for streaming and metadata delivery and they wrote a blog post about us. All of this work was just to get to MVP functionality of the expected behavior that was never discussed in the bigger cross functional meetings. And we still didn’t have decisions on many of the items we had discussed in the kick-off. If I had waited, we wouldn’t have started building anything and the whole project would have been delayed by two months or more.

Prototypes of the more contentious features got integrated into the existing MVP allowing us to test in place. Immediately, the conversations changed from theoretical to practical. Many of the most contentious discussions weren’t even issues once people actually used the feature. Other features were found to not work well and others were cut because they weren’t needed.

The features really started to gel once people could experience it. It completely reset priorities and focused the team on the pain points and most important features we needed to get done before ship. We ended up shipping the feature within the expected quarter and it worked smoothly out of the gate.

Takeaways

While this may seem like a one-off anecdote, this is one of many times I’ve pushed to start on something before the details have been solidified. Often encountering resistance from team members that we should wait for more clarity before starting. “What if we build the wrong thing?” or “What if the product team changes their mind?” are phrases I often hear when I’m pushing to start right away. The answers are “We will” and “They will” but the learning we’ll get along the way is worth the effort. It’s key to recognize those questions and answers usually don’t change much with waiting. Delaying starting will just delay those inevitabilities. Building right away will get to the right solution faster almost every time. There are many times where I’ve waited for a decision when engineering could have built all of the options within the same timeframe.

That’s not to say you shouldn’t hedge against the thrash. One key takeaway:

Start building the things nobody is talking about

Often, the things nobody talks about are a huge part of the project. These are the things everybody just expects to happen and you need to recognize there’s an implicit decision to do those things that you can take action on. Another way to hedge against the thrash is to work on the hard technical or backend parts first. Engineers are in the best position to know about the part of the iceberg below the surface and can start work on those parts right away.

This also applies to pure engineering as well. I’ve had a lot of discussions where engineers don’t want to start until they know exactly how everything is going to work. If you wait for that clarity, you will never start. The whole process is about iteration, updates and fixes. There’s almost always some part that you’re pretty sure about and building that part will create more clarity on the pieces you’re less sure about. Try to keep it short and simple like an outline rather than a fully polished product. Those ambiguous parts still need to get built and if they end up requiring changes on the part you’ve already built it’ll be easier if there’s less changes to make. Be sure to save time at the end of a project to polish and cleanup any experiments that may have been dead ends.

Planning

After writing all this, I don’t want people to take away that there should be no planning at all. I am a huge advocate of doing a design before starting to code. This is a proactive action… but it is often taken too far. Generally, I can design and plan out a sprint’s worth of work in a hour or two. A full day of planning/design can often get a whole team’s worth of work for a sprint or two. This is a good ratio. If you’re finding yourself doing design and planning for a whole week then that’s way too much and you need to break it up into cycles of planning/designing vs. doing. This is also a great way to break out of decision paralysis; not all decisions need to be made up front and a good coding session is a great way to get out of the deadlock. I’ll often squeeze in the designing/planning when I need to take a break from coding or in those dead zones between meetings where you can’t get into the zone.

Conclusions

Astute readers will say… “Hey, this is just Agile” and they’re right. What’s old is new again. Before the Agile process was coopted into a quagmire of ceremony and Jira nonsense, it was about building things. It was originally a counter to old-school engineering process where large waterfall planning is the norm. Building a bridge or a skyscraper is not something you just start building without some good plans in place. Software turns this calculation on its head because software changes are cheap and easy. So easy that you can iterate on ten ideas to find the right one faster than you can fully design and plan any one of them. The first bridges collapsed too, but since that iteration happened thousands of years ago, we don’t think about it. Those long lost engineers kept building until they figured it out. For software we can do that in a few weeks instead of a few millennia.