coRE
- Date
- 2019
- Team
- coUrbanize
- Industry
- Civic Tech
- Platforms
- Web, iOS
The company was looking to expand its business by creating a new product for teams developing commercial real estate projects. While current customers of coUrbanize used their platform to engage with communities during the approvals stage of a project, they would use coRE to manage projects in varying stages of completion. This new product would support their day-to-day operation across a full portfolio of projects. It would lead the company to a proper SaaS business model.
I inherited a few marketing mockups that bundled a set of features: portfolio-level metrics, project milestones and tasks, file management, and notes. It was impossible to deliver all of that at once even if doing so were a good idea. The team was not sure how to prioritize and where to start with an MVP.
The team suspected that file management would be a good starting point. A project manager at a leading Boston area real estate developer lamented how they spent a full day per week going through their email to download, file, and annotate attachments from contractors. After I prototyped and demoed a file management concept, it was obvious to the entire team that our solution was too narrow to be valuable. When I visited this project manager for observation at his job site office with Clay, a product manager I collaborated with, both Clay and I grasped that his email processing workflow was as efficient as it could get.
I looked for a different starting point and we chose to focus on tasks and milestones, the core of a project manager’s job. Competitive research and contextual inquiry led us to conclude that using any off-the-shelf project management software for our purpose presented barriers to adoption too great to overcome. So, I embarked on creating another prototype. This one started to resonate a bit more with additional project managers I showed it to as well as with some members of our team. But, I developed a gnawing impression that it was a glorified “todo app,” which to me seemed like a problem. Everyone has a system for managing their tasks. Even when a todo app is configured in the right ways, pre-populated with the right structure, and oriented around a right business process for commercial real estate development, a project manager’s preferences for how to keep track of tasks are entrenched and personal. Would our flavor of a todo app be enough to get a project manager interested?
Working through the second concept led me to a breakthrough. The milestones-centric product was always more about communication that surrounds and shapes milestones than it was about milestones themselves. While members of the project team need to check in, raise blockers, and communicate changes, I was leaving a larger group out of conversations taking place in the product. Those are the contractors that a project manager communicates with on a daily basis. The product should and could prompt those conversations to take place in it and in the context of tasks and milestones instead of overwhelmingly leaving them to emails. A smaller project team from the greater Boston area described how their communication happens in a hub & spokes model: a project manager communicates with each trade of external contractors frequently, and across different trades occasionally. They deliberately choose what information and which documents cross the trades, while the internal team has full transparency.
The last prototype that included external communications led the team to a higher degree of resonance among reviewers and traction in early testing. The process crystalized for me the importance of choosing the right early adopters and beta tester to provide feedback because their profile will have an oversize impact on what the product becomes. Sometimes it takes great effort to recognize which directions you don’t want to pursue before you can pivot. ▨