The 7 Minute Project Manager – Collaborative Design

The 7 Minute Project Manager evolved during the creation of the widely popular Official 7 Minute Workout mobile app. More general context and background can be gained from my initial article on this topic. My intent in writing this follow up article was to delve further into my experiences as the 7 Minute Project Manager by focusing the lens on the project itself; specifically, discussing what happened in the beginning. The early stages of the project can be best defined by what I would call collaborative design.

The project kicked off with a very small core team consisting of the Strategic Product Manager, the Creative Design Lead, the Project Manager (also filling the role as the product owner), and the Software Architect. We focused on general concepts and primary goals of the app. The Creative Design Lead immediately began creating rough sketches of what the user interface would look like. These rough sketches would be iterated over time eventually becoming the product wireframes – our bible for development. As more creative type resources became involved in the project, the project quickly became about creating a product that was “beautiful” – not a word typically spoken on most projects.

Design occurred at a very rapid pace. As initial feedback was gathered on one concept, that feedback was quickly turned into input for the next feature concept; keeping the consistency and the holistic flow of the app intact. To be clear, we were all about design and using design to drive requirements instead of the other way around – where requirements come first.

At this stage of the project, it was all about creating a product that was beautiful. But how do you create a project plan for “beautiful”? And is there a fear/risk that by using design to drive requirements that we would actually miss detailed requirements in the process? Yes, absolutely there is always that risk. But with schedule being the ultimate driver of the project and scope – defined as something beautiful – a close second in priority, there is nothing else you can do but to manage risk along the way.

As we moved further in design, I found myself needing to adapt quickly by wearing multiple hats. I would need to move rapidly from one task to the next, as I moved from one role to the next. Ironically, much like the design of the exercise circuit, this role switching was like moving from one exercise to the next, with very little rest in between. The only time I really had to evaluate project performance was at the end of a major milestone, again very similar to the My Performance section of the app where you evaluate your performance only after the exercise routine is complete.

Deliverables for this stage of the project were wireframes, concept designs, and creative mockups. Not your traditional requirements document filled with functional and non-functional requirements. To capture the requirements along the way, we annotated each of the deliverables above to ensure that our requirements were consistent with the overall design and to challenge ourselves when there was a conflict or contradiction. As the project manager for this project, I found myself managing to an ideal product end state, not a compartmentalized waterfall approach to deliverables.

We started off the project choosing Agile (specifically SCRUM) as our preferred methodology – being that speed to market was a key driver of the project. We all talked the Agile language, but there were definitely barriers to understanding exactly how we were going to use a collaborative design process to build a product from scratch, and magically break all that work down into two week sprints. To try to make some sense out of all of this and put a plan together, I had to work from the top down and the bottom up to build the schedule. Both approaches had to be done by working backwards from our launch date and then layering both schedules on top of each other to find the true dependencies, risks, and critical path for the entire project.

In this early stage, I needed to find that first schedule acceleration point to try and reduce overall schedule risk. We all quickly realized that we needed enough of the design complete so that product development could start as soon as possible. We knew that we could design enough quickly and continue to iterate over time. But we also knew that code development would be the longest leg of the project. It soon became clear to us that all paths led through the data model. If we could design enough of the product to understand what the data model needed to look like, then we could get started on code development and actually building the product sooner.

Now the trick was to determine how much of “beautiful” drives the project. Was functionality considered beautiful, or did it have to be fully polished? How much polish is truly necessary? Would our beautiful design work on both iOS and Android platforms? These questions would drive continued iterative design sessions. But we had to be careful not to allow ourselves to design to perfection. By using the project schedule, we determined when development would need to start and roughly how many sprints would be required to get us to our finish line end date. We used milestones like that to ensure our design sessions for functionality were one step ahead of when our planned sprint was for coding. Again, we needed just enough design to get started.

We knew we couldn’t be traditional Agile by doing two-week sprints with the end of each sprint being put into production. We had to have enough product features to call our product a minimum viable product (MVP) that would be well received by the market. In the world of mobile apps, product reviews and star ratings determine your success. If we didn’t put enough product features out, we would surely hear about it immediately from the market, which could spell the end of our product.

To ensure our proposed feature sets were in line with the markets expectations, we furthered our collaborative process by using past students/graduates and additional instructors from the Human Performance Institute, the birthplace for the 7 minute workout, to evaluate each creative design concept. We used pdf’s and some pretty amazing KeyNote presentations that essentially showed the navigation paths through the app. The navigation had to be quick, intuitive, and provide an experience that users like this were familiar with. In addition, we hired an outside company to recruit beta testers for us to make sure the general market perspective was understood as well. We went back and forth with review sessions before finding that right balance between what worked for a fitness instructor and what inspired the general user to want to workout and change their behavior. All in all, this feedback process was rapid, iterative, and rich with near-real time results, giving us the confidence we needed to ensure we were on the right path.

Communication tools quickly became essential in keeping the project on schedule. I needed something quick, lightweight, and virtually collaborative. Immediate feedback was required. We didn’t have the luxury of waiting for a formal deliverable review meeting to occur. Any delay in receiving feedback would immediately translate into project schedule delays. Therefore, it was required to become proficient in Cisco’s Webex collaboration tool, JoinMe, GotoMeeting, and Skype.

In addition, for document reviews in MS Word, providing comments in the document, but also embedding audio comments helped and was encouraged. Being able to hear the Strategic Product Manager explain their feedback provided more contexts and a clearer understanding of what they were trying to communicate. For wireframe and creative design reviews, we used pdf’s, embedding comments in the pdf’s and then recording ourselves using the Mac’s web camera (iSight), and then using Quicktime X to record our desktop as feedback was given. This technique, allowed a more comprehensive review of the document, where each team member could see and hear the reviewers feedback. We could literally watch the reviewer make edits as they commented on the material.

The above tools worked great for product deliverables, but when it came to actually building the mobile product, we immediately felt constrained by our inability to share, considering how many UDID’s we needed to share across the team. We quickly discovered a solution on the market called Reflector, an application by Air Squirrels, which worked excellent for show and tell of the mobile app in it’s early development state. The ability to take our mobile device and, through Airplay, reflect the device on our Mac or PC, allowed us to demo the mobile application to anyone we needed to.

As we moved pieces of design into development, we could all begin to see our “beautiful” product take shape. However, as our product became more tangible, the need to revisit design became a hard temptation to resist. It was quickly becoming clearer that, because of the intense speed of the project, we never truly defined in enough detail upfront what was required for our MVP. By not clearly having enough detail of what constituted our MVP, our continued beautiful design process would begin to wreak havoc on the schedule. Our desires to continually refine design were now bleeding too far into the schedule and downstream activities were quickly becoming compressed.

At a moment’s notice, my project schedule would completely blow up, just due to the rapid nature of the project and the impact to missed milestones. The only thing we could do when this happened was quickly perform risk mitigations. We needed to quantify the problem before we could determine the best solution. Most of the time that meant backlog grooming and scope reduction to downstream functionality. However, at some point, cutting too many features reduces your overall product value. Without a clearly defined MVP how would we know when we cut too much? I knew that to get our project back on track, I had to change the project from being one about beautiful design, to one of quantifying value. But how with such an aggressive timeline? This topic starts to get us into the next stage of the project, which is best saved for another article…

However, in the meantime, if there are specific questions or categorical topics you are interested in from this experience, please let me know and I will try to answer the best I can.

Don’t forget to leave your comments below.