Product Delivery Cycle

Key stages in one delivery cycle

 

Let’s recap what are the major stages during one delivery cycle:

 

Stage 1 Planning

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?

 

Stage 2 Gathering requirements and scoping

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.

 

The Scope Document

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: 

• Project summary 

• Project deliverables 

• Out of scope 

• Constraints 

• Assumptions 

• Risks 

• Timeline 

• Budget 

• Success metrics

 

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.

 

Stage 3 Design and development

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.

 

Stage 4 Implementing in staging environment and testing

In software development and testing, there are 2 major tasks happening in the staging environment - Quality Assurance and Bug Reporting

 

Quality Assurance

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

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.

 

Stage 5 Deployment

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.

Stage 6 Evaluation and gathering feedbacks

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.

 

Project Delivery vs Product 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.

 

Running agile during the delivery cycle

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:

 

 

Getting Ready for Deployment

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.

 

Onboarding flow

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.

 

 

Operation flow

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.

 

 

Go to market plan

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:

 

1. A landing page

2. A blogging site (with CMS) on the product website

3. Campaign mail service that comes with drip mail functionality

4. Transactional email service

5. SEO of the product website

6. Dynamic setting on the product website that allows the marketing team to constantly tweaking the contents to optimize conversion

7. 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.

 

 

Deployment Plan

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. iOS App deployment

2. Android App deployment

3. Web deployment

4. Backend end deployment

iOS App Deployment

• 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

 

Android App deployment

• 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

 

Web deployment

• 1 Content:

• 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

• 10 Design:

• 11 Favicon

• 12 Responsive Design

• 13 Images

• 14 404 Pages and Defensive Design

• 15 Testing:

• 16 User

• 17 Performance

• 18 Responsive

• 19 Cross Browser

• 20 Broken Links

• 21 Mobile Device

• 22 Site Speed

• 23 Marketing:

• 24 Set a Launch Date

• 25 Lead Capture

• 26 SEO

• 27 Start Blogging

• 28 Social Media Properties

• 29 Press Release

• 30 Syndication Automation

• 31 Social Bookmarks

• 32 Directories

• 33 Add Website to Email Signature

• 34 Sitemap

• 35 Tracking:

• 36 Analytics Tracking

• 37 A/B Testing

• 38 Heatmap Testing

• 39 Google Webmaster

• 40 Technical:

• 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

Backend end deployment

 

• 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