How Prioritizing Simplicity Helped Us Complete a Product in 56 Days
This past August, FordLabs embarked on a journey of total uncertainty with Project Jelly, a Ford X pilot project with the goal to build and launch a short-term e-scooter rental company in partnership with Purdue University — in 56 days.
Ambitious, especially coupled with the fact that we had to develop our own iOS app, somehow get our hands on a fleet of e-scooters, and build a boots-on-the-ground team to facilitate the day to day operations of our fledgling scooter enterprise — all with just a 5 person team.
With our deadline looming and the challenge laid before us, our (just formed) team honed in on one key theme: how can we prioritize simplicity? What steps can we take to allow us to work barrier free and deliver a great product quickly?
In the topics below I’ll be highlighting some key themes and steps we took to make our team successful and our product something that we were proud to be a part of.
First, what does barrier free mean?
Barrier free development, a term we came up with to describe this experience, means taking whatever steps possible to have as much autonomy over how we manage, build, and validate our product.
It’s common in large enterprises like Ford for other teams or departments to provide structure and direction around what you can and cannot do (e.g. what type of database you should use, what app hosting provider you need, etc.). This can be effective at scale or in areas of low volatility where things are predictable and work can be planned far in advance.
However, for products in areas of high uncertainty to succeed, you must move faster than the structure that surrounds you may allow. In these cases, and for us with Jelly, you need as much self-government as possible to do so. Our team had ownership over every aspect of our product, from the initial design to the final release. We managed the backlog, chose our own technologies, implemented the features, and deployed to production.
This isn’t the reality for many, and rightfully so. Not every product needs to be ran as an entrepreneurial effort, but some do. Our team stuck to lean principles and followed the build-measure-learn cycle made popular in The Lean Startup. This level of autonomy allowed us to move at the pace we needed. Take some time to consider how much autonomy your team has when it comes to the product you are building. Are you able to influence the decisions you need to so that your team can be as successful as possible?
Maximize the Work Not Done
Our goal was to build the leanest version of a product that would bring people joy to use while delivering meaningful value to our stakeholders, FordX and Purdue University. To achieve this, we only included features that we were confident our users absolutely needed, which allowed us to safely put all the nice-to-have features into the “work not done” bucket.
We did this by frequently combing our backlog of work and forcing ourselves to ask the question on each item, is this really necessary? Can I actually tie this feature back to a need that my end-user has? What would really happen if this thing didn’t get done? Would it allow me to get something more important and validated in its place?
One such example was related to a user’s ride history in the mobile app. Take a look at the mock up above. We thought it would be a nice feature to list the number of rides a user had been on as well as their cumulative miles ridden. This ended up being difficult due to a few technical reasons.
During our team’s standup, we mentioned that this story was taking longer than usual to complete (most user stories took roughly half to a full day to implement). A team member not working on the story mentioned that we emailed a receipt to each user at the end of their ride including the start and end location. We de-prioritized the story to support this functionality natively in the mobile app. Users were able to calculate how many rides they had taken as well as distance. Work not done.
Consider the work that your team is doing. If you’re on an agile team that has broken up your work into user stories, perhaps take some time and comb through your backlog of work and re-prioritize with your end user in mind. Don’t adhere to a plan just for the sake of adhering to a plan.
Can we automate this?
We were big believers in automating the boring and subjective stuff(cough code formatting cough). When pull requests were opened, our continuous integration suite (CircleCI) ran all of our tests, static code analysis, and deployed a development version of our system. We had a regularly scheduled build at 05:00 AM Eastern that would build and push a new iOS build to TestFlight as well as our API server to a staging environment. This made it easy to also use continuous integration wherever possible for building and pushing our software to production, while limiting the possibility of human-introduced error.
We pushed to production often, multiple times a day in some cases. It was important to us to have the shortest path to production possible, which meant we needed an automated and simplified workflow.
Every manual step you automate allows you to do something else more meaningful that contributes to the success of your product. People are invaluable and can think critically about tough problems — computers are cheap and stupid. Use them (computers) to do as much of the work for you as possible.
Simple ceremonies
We were a remote team, with two of us in Allen Park and the other three splitting time between Toronto and West Lafayette, Indiana. We had a daily standup via Zoom video conferencing at 09:15am EST with a weekly-ish one hour iteration planning meeting. We used a singular team slack channel for communication throughout the day. We held the occasional retrospective, using FordLabs’ RetroQuest for facilitating the meeting.
That was enough ceremony for us. The vast majority of our days were 7 to 8 hours of heads down work with small interruptions to check Slack or get on a video call. It was glorious, there was almost no need to check Outlook.
What does your team’s weekly calendar look like? Do folks ever grumble about too many meetings or not enough time in the day to get work done? Do people do that thing where they book a conference room for themselves so they can work uninterrupted? Perhaps you can brainstorm some ways to take some time away from meetings and put it back onto the calendars of your team.
Finally
We launched an e-scooter startup with close to 1,000 unique customers in roughly an 8 week time frame. Our experiment ran for one month, ending around the same time as Ford’s acquisition of Spin scooters. While this is by no means complete list of how we were successful, I believe that our effort to prioritize simplicity allowed us to move quickly in an area of high uncertainty. Plus, it freed up more time for riding scooters.
