Shepherding a product from a Proof of Concept to Production

Problem

In May of 2019, I came into a team struggling to develop a product within a tight timeframe. It was an innovative project meant to expose our platform to our customers, allowing them to create their own applications on our platform. This created privacy and security concerns, as we wanted to ensure that our customers' private information would remain safe. We couldn't use our existing delivery mechanism, as it didn't have the level of access restrictions needed for a platform of this scale. Our challenge widened when our current product manager left our company, and our deadline stayed the same.

Actions taken

In the beginning, our team was only made up of four people. That was me, our lead architect, and a couple of engineers. We had a six-month deadline, so our small team began reaching out to the core architecture team of our company. We showed them our roadmap, goals, current delivery mechanism, and the proposal we had created. Our goal was for them to tell us if this system would work.

When working on this project, our team was in a new problem space. It seemed like we were grasping at straws until one of our team members used his contacts within the core architecture team to start a series of weekly cross-team meetings. We tried to iterate our design within these meetings and let this other team sign off on it. It was important for our plans to be signed off because our product could cause an entire company outage if it didn't go well.

Once we had these weekly meetings going, we realized that our team needed the assistance of other teams for our process. We concluded that our product would not be feasible for delivery by our deadline date with the current team we had. We brought this to leaders' attention and conducted a cross-team meeting with the core architect team and other supporting teams. We presented that if our company wanted us to do this project right, we would not meet the deadline and would need more members working on this project.

After this meeting occurred, our team gained more resources, as well as tripled in size. Sharing our observations with the leadership team convinced them that this project was complex, and our deadline was set further back. Since we gained so much, we needed to onboard our new members with our roadmap and create a clear architecture vision.

The following eight months went by smoothly. We worked on our project and completed the code as scheduled. We began component testing, and everyone gave it their approval. When finally released, this platform was well-received by customers, and our team expanded even more now that it was a mature product.

Lessons learned

• Involve all stakeholders from the beginning. I recommend doing some reconnaissance to look at who is involved and who is involved in previous projects (especially cross-team projects). Having one-on-ones with critical players will create a layer of visibility needed when creating an overarching project.
• When you are in a tight timeframe or a crunch situation, make sure your focus is evident. Maximize your team's bandwidth and reassign other tasks to make time for what is essential.
• Create a common communication channel. This will help illustrate the visibility of your team and open the communication dialogue. Our team used Slack, and we gave regular weekly updates to begin with and then dialed it back to monthly updates.