As part of the PM class I’m attending we have to write our own case study to disect based on the concepts presented in class and via the case studies we’ve already taken apart. These kind of real-world, in real time type case studies are great learning tools as they force us to take a fresh look at our daily problems as well as help our fellow students through understanding theirs.
For mine, I actually synthesized a few different examples from my career into one conceptual study touches on a number of issues I’ve experienced into something that isn’t uncommon between my fellow technologists and myself. This is just a draft of what should become a core for a final project.
The company’s original “1.0” business model suffered from diminishing in profits over the last few years as technology changes, therefore the company has steadily ramped up new products under a revised 2.0 product vision led by the Global Management Team. Most of the product design and lifetime customer experience are already instituting the changes led by a Local Product Manager and the Local Acquisition Team is now making their migration to the revised strategy.
The traditional model used a PSMS (premium short message system) billing connection to partner telecos . Restrictions vary by region, but for the North American Group three main groups oversee mobile billing:
• Individual operator requirements (Billing Partners)
• Mobile Marketing Association & Canadian Telecom Association recommendations
• Federal and State / Providence regulations
However, in this legacy business the company had a firm understanding of how these rules and regulations affect the product acquisition. There were established benchmarks for:
• the conversion rates for acquisition funnels
• cost of acquisition
• the expected instant churn (buyers remorse, when a new subscriber quits within 24 hours)
• refund rate
• expected and actual lifetime value
These benchmarks allowed the company to evaluate how changes and optimizations affect acquisition and predict revenues and profits with a degree of accuracy.
The acquisition funnel was primarily static pages designed for feature phones and basic mobile browser capability. Managing the funnel was done by a series of teams:
• the local acquisition team a in New York which compiled optimization recommendations and oversaw the flow for changes
• NY team of billing connection API developers
• Global Resource Management in Barcelona, ES who manage developer availability
• The design and front end development team in Florence, IT
• The back-end groups and product QA in Milan, IT
• The compliance and legal in Atlanta, GA
• Sales support and customer service based in Delhi, India
In response to the changing mobile environment to smart phones and tablets complete with full browser capability as well as a move by the billing partners away from the restrictive PSMS billing funnels to new direct billing connections that are primarily regulated only by Federal laws and Billing Partner rules. The Product Manager in North America suggested a series of changes after a Product Review with the entire New York local team to the Global Management team based out of Milan. The three recommendations were:
• Moving to dynamic pages utilizing HTML5/CSS3 technology to replace the static pages so they acquisition flow better matches the end-product experience and integrate to the newly completed connections to the Billing Partners.
• Consolidating elements of the production team in the local offices to better respond to local rules and partner requirements
• Compiling new benchmarks for acquisition metrics that reflect better the 2.0 funnel
The initial recommendations were accepted by the Global Management and the Product Manager in NY set off to put together the new local strategy for implementation. A NY Project Manager (PM) was assigned to oversee the prototype development for the new acquisition flow. This PM had previous experience with the Global Resources team but came from a development background from within the New York offices which is how they were originally a part of the Product Review.
The initial requirements gathering by the PM included meetings with:
• The NY Acquisition Team
• The NY Product Manager who originally recommended the changes
• The NY API team who interface with the billing partners new API connections and the databases in Milan (but not directly with the Milan Back-end teams)
• A NY based Designer
• The Florence Front End (FE) Team
Some of the meetings were met with enthusiasm some were a struggle to gain full attendance and open communication in. This was initially identified as a function of the time difference and a language barrier. However, this also left some of the integration specifications incomplete and meant follow up meetings with the local API team and a local designer to try and fill in perceived gaps. Wherever there wasn’t full clarity the PM made notes and recommendations of her own in the plan.
The plan was reviewed only by the NY Product Manager who made some additional meeting recommendations particularly for Compliancy and QA as well as revised team integration but signed off on an initial prototype requirements to move to the dynamic pages using the recently completed new billing connections for now. The Product Manager condensed the plan and presented it to the Global Management while the PM went to work on implementing the plan.
The Project Manager began a series of follow up meetings and from that fleshed out the plan as follows in five major parts:
• Specifications for the page design and user interfaces from the local Acquisition Team
• The Front-end team requirements based on the user interface requirements
• The designer wireframing and initial design mock ups
• Front End implementation of mockups
• Backend hooks to Front End user interactions to trigger billing actions and database updates
From there dependencies were further identified between teams and milestones were placed to mark the work.
The Acquisition Team was excited to get started and were pushing for a very aggressive completion deadline for the prototype so they could begin user testing within their ad network. A formal kickoff meeting was superseded by Acquisition Team coming fully prepared with their requirements and foisting them upon the PM for execution by the FE team in Florence and local designer which reviewed it separately. The FE team was used to conferring with their own in-house Florence design staff and didn’t coordinate with the NY Designer on their input. Meanwhile the NY based Designer having the Acquisition Team sitting across from them worked closely for design clarification with them and not consulting the Front End team on how they would utilize technology.
The NY Designer was able to complete their tasks ahead of schedule so when the mockups were delivered to the Florence FE Team they were both unprepared for them and surprised by the requirements the NY Designer included. Due to a lack of free resources to re-evaluate the requirements the Florence Team fell behind on their element of the task. Realizing this, the PM tasked some excess local programmers with FE experience to work on the project instead thus keeping the close to the original tight schedule.
No other kinks in the production occurred and the prototype components were all delivered on time. The PM then reviewed the prototype with the Acquisition Team and Product Manager. It was immediately apparent there were several bugs in the flow integration between the front and back end but the design and most of the user experience itself gained immediate approval. The integration was sent for debugging and the revisions were accepted by the Product Manager but with several questions about compliancy and platform stability. The PM forwarded these concerns on to the different teams while the Acquisition Team began their user testing.
The user testing showed promise and the Acquisition Team pushed the prototype live where it lacked the overall conversion numbers immediately compared to that of the 1.0 existing benchmarks. It was then flagged for potential compliancy problems by the Billing Partners. When these two things occurred Global Management approached the Product Manager for an explanation on the problems with the flow and a request to potentially cease their usage.
1. Who do you identify as the stakeholders in the project and their relationship to it?
2. Which of the 10 breakdowns can you identify within the project?
3. At what point(s) can you identify the different breakdowns occurring?
4. What do you feel the Project Manager did correctly during those breakdowns?
5. What might you have done different as a Project manager in those breakdown situations?
6. Assume the role of the Product Manager for a moment. Would you recommend changes for a revised project to move forward, and if so, what would they be?
7. What other changes could you recommend to strengthen future projects?
8. There are two identified communication problems by the PM, do you feel those are the correct or only two that existed? If not, what else would you add in a post-mortem to the list?