Let’s recap what are the major stages during one delivery cycle:
This is the stage when all stakeholders are brought together to make consensus on what the product or project needs to achieve. At this stage, we focus more on the business goal or operational goal, while the exact features and functional requirements will be dealt with in the next stage. Please bear in mind that this is the stage where budget, resources and time constraints will be discussed so an accurate scoping can be carried out.
Once the crucial business or commercial goal is clarified. Typical key questions about project and development planning to be addressed will be:
What should be the project approach - should we use a custom development approach or adopt off-the-shelf solutions? Will a phased rollout or a single one-time launch be required? Will there be a pilot run or test drive?
What are the team members for the development project and what roles each member will play? Which roles will be taken up by in-house team members and which roles will be taken up by external partners?
Do our project or product owner have enough technical knowledge to answer all the development questions or we will have to seek an outsourced digital manager to step in as the CTO or CDO role?
This is the stage where you will have more in-depth rounds of stakeholder interviews and a list of features and functions required can be scoped so we can proceed to pin down scope, timelines, final project plans, and budgets and document it all.
This is also the stage where all the important documentation of the project will be written or at least outlined and drafted. It is not uncommon to hear complaints that since we are adopting the agile methodology, no documentation is needed. We could respectfully disagree with this viewpoint. From our experience, the best approach is indeed a hybrid of both the waterfall and agile methodology. While documentation, however preliminary it would be, is something that should not be missed.
With your initial plan for the plan and subsequent breakout sessions, you will have ample material to create your scope document. Simply put, a scope document is a statement of the project “deliverables,” what the project team will deliver to the business when the project is complete.
Here are the components of a good project scope document:
Out of scope
It is absolutely essential to be as visual as you can when you are scoping your software project. Provide diagrams and sample screens to accompany your scope. Clearly defining and visualizing the project is arduous and it takes time, but it is one of the most important things you can do to ensure the success of your project.
As your project moves out of the requirements and specifications stage and into development, many business folks and project team members may feel very eerie when the noise and commotion suddenly evaporate. But behind the scenes your designers and programmers are working 60 hours a week and have 200 issue tickets to address:
A UX person will refine the low-fi wireframes gathered from previous stages into high-fi wireframes for sign off. As the UX person creates wireframes, a designer will be doing the first visuals, demonstrating how those wireframes can be enhanced to create a beautiful piece of software.
Programmers are coding, even though wireframes may not be fully done. Many back-end tasks can be done in the absence of visuals. Even many front-end pieces can be roughed in. If your team is working in a more Agile style, bits of functionality are starting to emerge and to be shown to the project team and even business stakeholders.
The project manager is tracking everyone's progress and seeing where things are going off schedule.
Initial testing plans are being considered, especially when agile is adopted, iterative testing happens regularly at the end of each sprint.
In software development and testing, there are 2 major tasks happening in the staging environment - Quality Assurance and Bug Reporting
QA begins with defining what are called “use cases.” Think of the happy path example. Use cases are all the journeys through your software that a potential user could take, both happy and “unhappy.” Someone needs to sit down and map out all the possible journeys so they can be tested. This sounds like a daunting task because it is. It's mostly a pile of snow–type of task, but it's a big one. Many of the paths and items that must be tested are those that might not occur to the “normal business user.” One is the “close the browser and open it again” scenario from the previous e-commerce example. Another test might be, what happens if two people log on simultaneously with the same password? Other use cases have to do with security-related issues, like testing the input forms on a site to see if they are vulnerable to hacker exploitation. The QA process is the systematic run-through of these use cases in the software.
Bug reporting is the data that comes out of running all these use cases. When something does not work as expected or completely fails, a bug is reported. Bug reporting is usually handled via a bug tracking system, such as products like Jira or Bugzilla.
Deployment is not really a single event but more like how you roll it out to the market once all testing is done and the product is market-ready. This is a phase when a lot of cross-team collaboration would happen. When preparing for a deployment (or a launch), a project manager will need to work with the marketing team to ensure the onboarding design is functioned as planned, all analytics tracking is in place, etc. The project manager may also need to work with the operation team to make sure the related sales persons, customer support team are standing by when new users join in the service. More will be discussed in details in the next section.
Evaluation can be mainly divided into 3 types - market, users, and performance. Market evaluation will be addressing how well the features and functions are designed to achieve an optimal product market fit; usability evaluation will be addressing how well the UX and UI are designed that allows the users to get the most out of the product according to our original intention. The performance evaluation will be addressing how well the product is architected and developed, this will include a wide range of performance issues including speed, stability to security.
However, the evaluation phase is where the goals of project management and product management will take on very 2 different paths. The goal for a project manager at this stage is to aim at fixing bugs and dealing with any outstanding change request but at the end, the project manager will be looking for a project sign-off so as to declare that the project has been completed. Granted project management usually includes the maintenance phase, but this usually involves making sure the software is stable and compatible when the operating systems are changed.
While for product manager, they will take on a very different mindset. They pay close attention to not only the performance evaluation but also the market and user evaluation as the product to them in a living organism and it’s an ongoing process. Hence after one deployment and gathering substantial amount of evaluation information, product manager will lead the product into another delivery cycle.
As illustrated above, a cyclical delivery cycle could be the biggest difference between project management and product management:
Project managers look for a sign off. After dealing with some more post-launch bug fix and change requests, the project manager’s goal is to close one project and move it into maintenance mode.
While from the product management point of view, a product delivery cycle is repeated and ongoing as long as the business that the product represents is still up and running.
Please note that one sprint does not mean one delivery cycle. Agile is more a mindset and an iterative approach that can be applied during the different stages of a delivery cycle. A visual representation of the relationship between a delivery cycle and a sprint will be something like this:
When it is time for the product to go live, there are 3 groups of people that a product manager will work very closely with. They are the UX team, the marketing team and the operation team. The UX team is crucial when it comes to go to market because they will need to make sure the onboarding flow and onboarding process is extremely smooth and self-intuitive. Although the onboarding process should be built in the product since the wireframing stage, it usually is not until there is a launch deadline that the marketing team and the operation team can be brought together for a final round of review to make sure all details are covered.
The onboarding flow is the sequence of steps that users take when they use the product for the first time. There is not a single rule of what a good onboarding experience would entail but it is worth going through all the details or even an internal training to make sure all team members are well aware of all the steps. This is especially true for FinTech products that take lots of time, the compliance officer will need to be the gatekeeper for all the regulatory requirements.
Following is an example of Expensify’s onboarding flow. Expensify is an app that helps users track, manage and report your expenses. This financial app has a nice user onboarding flow.
Before signing up, the app screen tries to communicate the benefits of the app to the users.The sign-up process of Expensify is simple and straightforward, yet with style. The app has a clear message and CTA, letting users know what to do. For the first time using the app, Expensify guides users with pop-up messages, helping the user know what to do.
Why is drawing out the operation flow so important? Imagine you are trying to brief the customer support team how to review and process and online insurance coverage application, do you think they can imagine all the necessary next steps by simply showing them the app and the screen cap? Just like the insurance website example here, in order for customer support staff to comprehend clearly how one online submission is processed, an operation flow as such is extremely useful.
The marketing team can be very creative with their go to market plan. They can come up with promotions both online and offline or even a convergence of both. As a product manager, your job is not to critique whether their marketing plans are going to work or not, but to understand when integration is needed especially when conversion is driven from an online presence of the product or the conversion happens online.
A typical conversion flow would usually entail the following parts:
As a product manager, you may not have noticed that there is the expectation from the marketing team for some additional development to work with the marketing plan. Just using the above conversion flow as an example, the marketing team would be looking at the following development:
A landing page
A blogging site (with CMS) on the product website
Campaign mail service that comes with drip mail functionality
Transactional email service
SEO of the product website
Dynamic setting on the product website that allows the marketing team to constantly tweaking the contents to optimize conversion
Tracking and analytics that allow the marketing team to monitor the campaign performance
I could confidently say that lots of inexperienced product managers have been caught off guard by the above requirements before when the marketing team thought the above have been embedded in the product.
Fortunately, more and more digital marketers realise that it is indeed their responsibility to raise up these requirements to the product manager early on during the cycle or better still, they themselves have the ability to leverage some third party tools such as landing page generator, drip email service provider, Google data studio, etc. to build the campaigns that they need. The sprouting of MarTech is offloading a lot of pressure from the development team. To increase efficiency of digital marketing campaigns, the product manager only need to communication with the marketing team to work on the integration with these third party MarTech tools.
The third deployment preparation will be the technical development plan. Unless specified, this plan is usually prepared by SA and the product manager will be monitoring the progress. The technical development plan are usually developed into 4 sections:
1 Building machine OSX and Xcode is not beta version
2 Check for HTTPS usage at production environment
3 Get the provisioning profile and the app distribution certificate
4 Mark the provisioning profile and certificate expiry date
5 Backup the p12 of the certificate
6 Mark the server push certificate expiry date
7 Screen caps
8 App icons
9 Validate the build in Xcode's organiser
10 Notify backend on app upload to prepare deployment when release
11 App QA testing result
12 Double check on the previous app store reject cases
13 Check if there are unnecessary use of advertisingIdentifier
14 Run code analysis
15 Upload production build to TestFlight for deep links testing in product build/environment
16 Confirm Fabric.io framework removed
17 Confirm the App ID and app secret for connected social networks and SDKs
18 Confirm if all debug logging is disabled
19 Attribution properly made for 3rd party libraries
20 Check for any unnecessary SDK used
21 Double check connection to production environment
22 Apple account and iTunesConnect login credential
23 Create new app or version on iTunesConnect
24 App submission form
25 App display name matched
26 App version number matched
27 No background modes for BeaconCube SDK
28 Disable app udpate alert prompts for App Store review
29 Confirm release manually or automatically
30 Update project README file
31 Tag commit on Gitlab
32 Merge the code to master branch on git
1 Check for HTTPS usage at production environment
2 Google Developer account login credential
3 Get the keystore
4 Backup the keystore
5 Screen caps
6 App icons
7 Notify backend on app upload to prepare deployment when release
8 App QA testing result
9 ProGuard enabled
10 Run code analysis
11 Confirm Fabric.io library removed
12 Confirm the App ID and app secret for connected social networks and SDKs
13 Confirm if all debug logging is disabled
14 Confirm app's overall size
15 Confirm only requesting necessary app permission
16 Check for any unnecessary SDK used
17 Attribution properly made for 3rd party libraries
18 Double check connection to production environment
19 Create new app or version on Google Play
20 Make sure the “versionCode” number in build.gradle is higher than the current one on Google Play Store
21 App submission form
22 App display name matched
23 App version number matched
24 Confirm release manually or automatically
25 Update project README file
26 Tag commit on Gitlab
27 Merge the code to master branch on git
28 Upload mapping.txt created by ProGuard to Google Play Developer Console
2 Typography and Layout
3 Spelling and Grammar Consistency
4 Check Context
5 Ensure No Test Content on Site
6 Check all ‘Hidden Copy’
7 Check Forms
8 Proof Read
9 Legal Pages are in place
12 Responsive Design
14 404 Pages and Defensive Design
19 Cross Browser
20 Broken Links
21 Mobile Device
22 Site Speed
24 Set a Launch Date
25 Lead Capture
27 Start Blogging
28 Social Media Properties
29 Press Release
30 Syndication Automation
31 Social Bookmarks
33 Add Website to Email Signature
36 Analytics Tracking
37 A/B Testing
38 Heatmap Testing
39 Google Webmaster
41 Code Validation
42 Page Redirection
43 Transactional Email Delivery
44 Admins get email when site error happens
45 Monitoring Set up
46 Back Up
47 Graceful Degradation
48 RSS Link
1 Add auto start service
2 Data backup
3 Setup CPU and disk monitoring tools
4 Backward Compatible
5 Add email/sms/teamwork alert for server error
6 Production server location and domain
7 Point to Domain instead of IP
8 Index SQL database
9 Verify SSL cert on production server
10 Sign off by QA