Enterprise MVP - Made in Captives and ODCs

The 5 steps listed below are from the session: Design MVPs (Minimum Viable Product) for Enterprise Customers by Owen Rogers from Pulse Energy. This talk was given at the Management track of the Agile India 2013 conference that was held in Bangalore, India on Feb 27, 2013 and Feb 28, 2013.

To build Enterprise MVP

Step 1: Start with fixed known constraints

Step 2: Defer commitment on everything else

Step 3: Leverage external products and services as much as possible

Step 4: Start simple and iterate quickly

Step 5: Tell a compelling story - user journey - focus on workflow not features

So can Agile teams in captive centers and in outsourced product development centers (ODCs) truly contribute to building MVPs?
For the large part, this ask may be a challenge since in captive centers the product manager is located onshore or in the parent company and in ODCs teams may be far removed from the real users of the solution when the real users are the customers of the client.

I recommend these three initiatives to enable Agile teams in captive centers and ODCs to contribute effectively to the whole process of building enterprise MVPs:
1. Build domain expertise
2. Create opportunities for customer contact
3. Have the product manager travel to the Agile team locations at significant milestones

Building domain expertise leads towards:
- building a knowledge base from which requirements can be validated
- ideating based on the knowledge gained about the painpoints and customer workflows
- increasing confidence in the solution
- actively contributing in the release planning phase

The organization should make allowance for teams to engage with customers face-to-face in user group meetings and product conferences. When the big picture of why they do what they do becomes clearer to teams I believe that Agile teams will be able to create realistic acceptance criteria,  simulate the right deployment environments, and identify customer candidates and/or scenarios for usability tests.

For every sprint 0, the Product manager can travel to the location of the Agile team which would help in:
- face-to-face communication which trumps the greatest advancement in telepresence
- providing an opportunity for Agile team members to directly contribute to the product backlog by making their suggestion, backed by research, to the Product manager
- optimizing the time taken for initial product backlog refinement
- building an Agile team that includes the Product Manager as the Product Owner

These recommendations are drawn from my experience as a Product Owner for Pivotal CRM at CDC Software (now Aptean).

Got 'em on the Same Roadmap

Sharing an account of a product release strategy in response to a situation that triggered the release. This is a first person account as a Product Owner.   

Scenario: 

A B2B CRM company, with a common platform on which were built add-ons for Financial Services, Marketing, Service/Support, and Homebuilding acquired a marketing product, (called MP for simplicity). MP had a loyal customer base renewing maintenance contracts annually and demanding new features to support their business.

Problem: 

• MP and the flagship CRM had independent roadmaps which brought challenges when aligning Sales and Marketing with the release pitches. 
• Features on MP were overlapping marketing features already available on the flagship CRM product. 
• Customer sentiment was that with the acquisition MP did not get as much attention as required to cater to their needs 
• New customers preferred the flagship CRM product 
• Share of the revenue that MP brought in was declining 
• MP had a dated technology base
• MP's user interface left much to be desired
• Cost of deploying MP on a hosted environment was high
• MP's support for mobile was text-based

Goal:

Bring the zing back to the marketing vertical

Time constraint:

Deliver in 3 months

Strategy:

To build a marketing automation add-on to the flagship CRM that included the most valued features from MP and the existing features on the flagship CRM.

Roadmapping activities in this approach:

1. Reviewed the features of the flagship CRM so that the marketing add-on includes an enhanced version of MP's unique features, and removes duplicate features
2. Worked with the Gartner analyst for Marketing to understand the industry trends and marketing automation vendor selection criteria
3. Reviewed support incidents of MP to understand the painpoints
4. Included the migration and feature integration plan in a common roadmap

Customer retention activities in this approach:

1. Offered the flagship CRM product with its hosting capabilities, mobile support, and improved user experience to MP customers
2. Drew up a migration plan with tools so that customers can confidently migrate their data to the flagship CRM with the marketing automation add-on
3. Presented the common roadmap

Post the roadmapping activities, worked with architects, user experience specialists, and the development team to design and deliver the first release of the marketing automation add-on in 3 months. The first release included the most important features of marketing automation that could be delivered in 3 months by 1 development team.

Results:

The Marketing Automation add-on:

• Was well-received by existing and new customers
• Moved back into a top revenue earner on the flagship product as well
• Received rave reviews from market analysts

The Product Manager and the Agile Testing Strategy

On an Agile project, the application is being built incrementally with every sprint adding to the functionality. As a result of this approach, Developers are constantly adding to the codebase impacting the existing functionality. While Agile software development ensures faster time to market and greater transparency for the stakeholders, it also stands for finding defects earlier in the cycle and raises the bar for quality. Agile testing requires QA engineers on the Agile teams to test quickly, incrementally, and contextually while staying within acceptable defect limits. In this scenario, an Agile QA engineer employs "smart" testing strategies and tactics to meet the demands of an Agile project.

Smart Testing

Smart testing requires the application to be tested incrementally - meaning while the user story is being coded, the QA engineer plans for the test cases and scenarios in the immediate vicinity of the story and tests the application as soon as the developer is done coding. Individual user stories are tested in this manner and when the build is created for the sprint scope then QA accepts the build, regresses the system, and skims over the user stories of the sprint with greater focus on the impact on the surrounding areas of the functionality delivered in the sprint.

As you can well extrapolate, this approach can add to the quantum of build level testing that is done in successive sprints. To optimize on the testing scope vs effort, another facet of smart testing, which is testing prioritized system workflows is undertaken. Testing in this prioritized order while optimizing the effort does introduce some risk which can be handled to some extent by doing adhoc testing around the major workflows.

Product Manager's Contribution

The Product Manager's contribution to the smart testing approach is to validate the workflows that are being tested and ensure that the tests cover features that are indeed the major workflows at the customer end. This validation begins with the review of the Test Plan that QA comes up with at the end of the release planning or sprint 0. The validation continues on during the iteration while reviewing the scope of coverage of the test cases at the user story level. The validation concludes when looking through the prioritized list of major workflows that QA plans to test as the functionality scope increases. 

Additionally, during acceptance testing, the Product Manager can take into cognizance the scope of QA testing and review the product against the acceptance criteria. 

The Product Manager is able to collaborate with QA on the testing strategy by drawing on his/her knowledge of: how customers use the product, features that pre-Sales demo to prospects, the features that are obligatory requirements, and those user stories that effectively out-pitch the competition and find favor with analysts.

In case of a complex product, it may not be possible for a Product Manager to be involved with the Agile teams everyday. In this scenario, the Product Manager's contribution can be scaled by taking the help of a proxy Product Owner who works closely with the Agile teams.

In this way, a Product Manager can ensure that the Product is being built right by having a stake, albeit minor, in the testing strategy of Agile teams.

My Top 3 Areas that Product Managers Adapt with Agile

In a product development organization, product managers are placed at the center of the productizing process. In this capacity a product manager strategizes the product's path to development culminating in bringing value to customers and profitability to stakeholders and business owners. When development teams adopt Agile, the Product Management team should also be brought under the influence of Agile values and principles because the Agile team is dependent on Product Managers for direction with respect to "what to build."

Here are my top three areas which Product Managers must adapt to flourish in an Agile environment:

Roadmaps – Product Managers own roadmaps and this artifact in a Agile environment needs to be reviewed with the Agile team at the end of every cadence (release) so the team can align itself with the next prioritized item and at the beginning of every cadence in order to set priorities. For their part, Product Managers need to be aware of the release cycles of Agile teams and ensure  that the market research and other activities leading to executive buy-in and budget approvals are in time for the Agile team to start working on the release.

Increased Transparency -  User stories are based on the value that it brings to the user. This value is explicitly captured in every user story after the Product Manager talks with customers and analysts, and researches the market factors. Every person on the Agile team is encouraged to question the value of the user story which requires the Product Manager to have a granular understanding of the impact of a user story on customers and the market. 

Sales and Marketing Interactions – A Product Manager needs to train marketing and sales teams through demos, documents, and conversations on the products and its features so that there is effective messaging and lead conversion. In an Agile world, the Product Manager can prep the sales and marketing teams with confidence since he is aware of the nearly releasable features that are being churned out by the team sprint on sprint. 

Presented this topic at Agile Tour 2012, Chennai, India

Leveraging User Ecosystem for New Products

Here is a collection of opportunities that I have leveraged while trying to build a product that catered to target user requirements. Each project included leveraging one or more of these opportunities.

• While getting started:
• Build target personas - for a new product, you may not have existing customers whose input can validate feature sets, but what you do have as a product manager is the business goal which would illustrate the market segment. The users who comprise the target market segment can be developed into target personas around which workflows and features can be built.
• Research analyst reports and domain publications - to understand trends and players and   details on the facts and figures based on which you could understand the market in which you want to play.
• Network with field agents - Talk with colleagues who are Solution Consultants, Sales Engineers, Professional Services for input on what the market is asking especially if you are building a product that is related to the existing product portfolio. Strike up a chat, even one at the water cooler could be quite informative.
• Contact target users - Interview or survey target users to understand how they are currently meeting the requirement that your product aims to resolve. Use this input to align  product workflows with mental maps to shorten the learning curve for users and increase product acceptance. 
• During product development:
• Regular live demos - Build the product incrementally and demo the increments to channel partners, Solution Consultants and thought leaders to elicit feedback. Build a feedback loop into the development process so the team can incorporate the feedback with minimum disruptions and the provider of feedback feels heard and valued.
• Host recorded demos - with a short, crisp narrative and a simple way to provide feedback - perfect for target users who prefer to watch demos on their time.  
• Visible requirements - Publish the requirements gathered in a selective access portal that is visible to customers, partners, and target users so they can confirm your understanding of their requirement and can also be updated when the requirement moves up to be implemented
• Towards the end of a product development cycle
• Access to a sandbox - Provide access to a stable build through a sandbox so target users or their proxies get a feel for the real product. Such a provision at a Beta stage can be a source of confidence for prospects to know what they would be getting into and for the development team to know what prospects are looking for.
• Conduct usability tests - Specify a set of tasks that the user needs to accomplish using the product. watch how the works her way through the product to complete the tasks, areas that confuse, and areas that delight. The results can be a mine of information for feature design tweaks.
• Speak at user conferences - A perfect opportunity for cross-selling or up-selling the new product. Being able to pitch to multiple prospects while enabling prospects to leverage on each others' understanding of the products selling points could pave the way for a shortened sales pitch.

The Customer's voice - it's out there

As an excited Product Manager with the team that put together the first construction sprint of a greenfield product, I booked a meeting room and invited other Agile teams and stakeholders to the demo. No sooner did an excited team member demo the features that we started getting feedback and comments.

The screen has too much white space - why can you not use the real estate.
I don't think that companies store photos of their contacts.
Displaying each record in a tile - is pretty but occupies space - grid is so much better
How do I read the tiles, top to down, right to left or a mix - its confusing
Don't you plan on including sorting or filtering?
I can't see how an organization can work on a complaint without performing a series of steps

So what do I do next as an Agile Product Manager, update the product backlog to incorporate all of the feedback? Not just yet. The discovery of this set of feedback calls for validation by the target customer and customer representatives. At the end of the validation activities, my target customers or representatives may well provide the same feedback, and that's when I update the product backlog to reflect the value that the customer is expecting from the product.

For a greenfield product, my best bet would be folks that fit the user profile on which the product is modeled. Another set could be customer representatives, folks who have been on the field listening to customers - like sales engineers and solution consultants.

The voice that determines the product backlog is out there, it's up to the Product Manager to reach out and listen.