If you’ve worked at an early-stage startup, you’ve seen a system break down before. There’s a process in place. It works (or the team thinks it works). It breaks. The team keeps using it because they don’t have time to fix it. Eventually, the team accepts that it has outgrown the system. They build and adopt a new one.
Requirements Gathering & Understanding the Problem
I knew that the project management process wasn’t working, but I wasn’t sure why. I needed to fully understand the problem before I could even consider solutions. I spent time looking over the system and trying to figure out exactly where it was breaking.
I discovered four major flaws that were causing the existing system to behave ineffectively:
- It was designed for one team working on one project. Our team frequently worked on a few projects at a time.
- It did not have a centralized location where I could track tasks easily and quickly. I was using the Kanban board while the engineers were using the issues tracker. It was hard to see what people were working on, so I’d often need to spend upward of 30 minutes to figure out what people were doing,
- I’d often have to spend a lot of time explaining what I meant when I wrote feature descriptions.
- We had a lot of structure and steps to follow, but it wasn’t making us more effective. We were mired in process, but it was only slowing us down.
Once I understood the problems with the process, I was able to set four concrete goals for the new system.
- The system needed to make it easy for a team member to see all of their tickets across multiple projects.
- The system needed to be straightforward, so I could quickly see what each team member was working on.
- The system needed to reduce the friction caused by back-and-forth conversations about the contents of tickets.
- The system needed to fit in with our core value of minimal process. In other words, we needed just enough process that it made us more effective.
I decided to treat these goals as KPIs. With my goals in hand, I began to research existing solutions.
Market Research
I sat down to research how other teams were approaching project management and what technologies they were leveraging to do it. I paid close attention to the tradeoffs those teams were making when they chose a platform.
I had used Pivotal Tracker in the past and found that while it offered in-depth analytics, it paid the price in usability and flexibility. Github Projects linked with Github but the engineers never wanted to use the Kanban board feature and often forget to close their issues. Keeping track of who was working on what began to take up 80% of my day.
Jira, a favorite of big engineering teams, felt too heavy for our small engineering team. Google Sheets would have made sense to our stakeholders but required too much upkeep for our needs.
Finally, we settled on Asana. The UI is pleasing, I could create both lists and Kanban boards, and it felt flexible.
Prototyping
Once I felt I had done enough research, I picked the smallest and most well-defined piece of the process that I could think of: the engineering workflow. I designed an MVP that we could test almost immediately. I started out with two “features:” a Backlog and a Sprint Board.
The Backlog was a prioritized list of tasks.
The first iteration Backlog
The Sprint Board, on the other hand, was a Kanban board that had 4 columns. Ready, In Progress, In Review, and Done.
The first iteration Sprint Board
And that was it! Once I confirmed that everyone on the team had bought into the adjustment, we went ahead and started to use the process. The key was that I immediately began asking for feedback, especially around the goals I was measuring the process against.
User Feedback & Iteration
My team was happy to give feedback. One of the most important suggestions came from one of the engineers on the team. He asked if we could add more columns to the Sprint board. In my attempt to keep process as minimal as possible, I had allowed for too little complexity.
After some back-and-forth, we added two more columns to the board––Ready for Release and Live. This change made it easier to see what people were working on at a glance and it reduced in-person conversations about tickets.
As the number of projects we were taking on multiplied, my team also brought up that it became difficult to understand which tickets belonged to which project. We began to add the name of the project to the beginning of the ticket’s name.
For example, if the ticket was named refactor scheduler feature we would change it to: [CMS] refactor scheduler feature. That meant that the ticket was associated with our CMS, rather than our Alexa skill.
This small adjustment allowed us to remain flexible while still fitting in with our core value of minimal process. We could still use one board to work on multiple projects, instead of creating a different board for each project and having to check every single one of them.
Lessons Learned
- Building a system is building a system, and it’s possible to borrow from other disciplines. Project Management at an early-stage startup is not as different from Product Management or Engineering as I had initially thought.
- Solving a problem tends to reveal flaws in satellite processes. For example, once the engineering workflow was ironed out, I realized I needed to iterate on the design and the product processes.
- It’s crucial to test your assumptions.
- Ask your team what they think. There’s nothing better than user feedback! Something that works for you might not work for your users.
🌟 If you liked this post, make sure to follow me on medium, follow me on twitter, and clap for this post! 🌟