This photo is unfortunately not successful base stealing.

Stealing a Base in Product Development

In an ideal process, design would be working in close collaboration with engineering teams on short product cycles. Plenty has already been written about Lean & Agile methodologies in product development, so I’m not here to explain them further. It’s generally accepted that these methodologies are critical to the success of a modern startup. But is that always the case? Could it make sense to put those processes aside and run with methods that more closely resemble waterfall?

At Axial we’re currently answering some of those questions. We’ve found a few important and immediate business goals that we’re determined to solve as fast as we can. For context: Our engineering team is just coming out of a complete technical refactoring of our product, and there are even bigger projects on the horizon. Because of our focus to pay off the technical debt, it’s been 7 months since our customers have seen major new improvements to the site. That’s some pretty big lag to catch up on. It’s imperative that we move quickly to build better experiences for our customers and validate some of the assumptions we are making about how the product should work.

Given the amount of work we wanted to get done in the timeframe we have, it quickly became apparent that it would not be possible with the engineering resources we already had in place. There was simply too much to do. We needed a burst of speed to get where we wanted to go — we needed to steal a base, if you will. We needed something faster than just hiring more engineers. So we decided to contract a team of remote engineers to quickly deliver the front-end of a large project. This will give our internal teams time to fix refactoring-related bugs that may come up, and will allow them to focus on working with necessary changes to our existing application, so the project is executed in parallel, and the different streams can wrap up at roughly the same time.

Here you see a product strategist examining the risk

When stealing a base (this a sports analogy, bear with me), you’re playing a risky move. The player is more exposed, and by leading the steal the player is at greater risk for getting tagged out in the game. The rewards for successfully stealing the base are pretty great however, and usually make a successful effort worth while. If the runner advances, your team is significantly closer to scoring a point, and that’s what make the maneuver so appealing. It’s a strategy play that’s sometimes available, but has to be used carefully.

The risks we take on by working with an outside engineering team are kind of similar and there are certain trade-offs that have to be made. Will the work be good? Will the project be done on time? Will it stay within budget? Will we be able to integrate the new code into our own work? Will the other team understand our designs and product decisions?

Accountability and communication are key to mitigating some of the risks of working with an outside team. We’re just at the beginning of this process, but here are some of the key points we’re trying to stick to:

Having one point person on their side. Someone who is able to communicate our feedback to the team and share concerns or questions to us.

Trusting their working process. Instead of spending time to ramp up on incorporating their methods into our own, or expose them to our processes, we’re going to focus more on giving feedback to the outcomes.

Frequent communication and check-ins. We’re scheduled for twice a week meetings at the beginning and end, with feedback given quickly.

Preparing yourself to steal the base

Bring key persons from their team into our Slack channels. Having members as part of our Slack channel will give them more context to questions that come up and decisions made.

Have clear stories and designs prepared. One of the most important things we can do to help contribute to the success of this project is making sure designs reflect exactly the PM stories created. Having organized and detailed design mocks and user stories is essential.

We are excited, if a little wary, of these new developments. Certainly by the end of the project the team will have learned a lot. Hopefully we will also have scored a few points too, making the risks worth it.