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.

The three wheels of the Agile auto rickshaw

The Agile adoption in an organization is a 3-wheeled vehicle of change.

The first wheel is the process – which for us is SCRUM. The SCRUM process establishes ceremonies and practices that enable the Agile team and stakeholders to communicate with each other for the successful implementation and delivery of a software project.

The second wheel is the energy of Agile adoption – the adopter’s mindset. Molding the traditional mindset to one that is open to the Agile way is a challenging task for the Change Agent(s). This wheel establishes a mindset where every individual Agile team member is responsible and brings to their task their best self. Mutual support and respect and a drive to succeed together, with the inspect and adapt perspective are the spokes of this wheel.

The third wheel is that of technical Agile excellence brought about by practices such as pair programming, test driven development, refactoring, continuous integration and deployment. When delivering in iterative cycles it is easy to code and test the traditional way while paying obeisance to SCRUM ceremonies and mindset. This model will simply fail in the long run unless a disciplined approach to the technical aspects of Agile is not adopted.

When I look back at the order of adoption of the three wheels – we are working in the order of process-mindset-technical. However I don’t believe that it’s the prescribed order, the order of adoption would depend on the organization’s framework and what would work best. For example if the Agile team members are highly technical and do not subscribe to the process-mindset mumbo-jumbo, you may want to begin with the technical wheel and then move in the other two wheels. Another example is if the organization is already on a path of self-managed teams, then perhaps it would make sense to start with the mindset and roll out the other wheels afterwards.

After the initial enthusiasm of adoption fades away, it’s very natural for the Agile teams to fall into old grooves, drive off the track, or practice without value. These wheels need regular lubrication to keep them moving and a shot of enthusiasm to keep them moving at optimum speeds. We are using a team of evangelists who play this role while doing their everyday jobs. Random health checks to ensure that alls well, organization of sessions, facilitation of SCRUM ceremonies for problem areas, building relationships with the Agile community at large are some of the undertakings of this team.

We roll on.

Agile - Retrospectives - 3 methods

Here is a summary of the 3 styles of retrospectives that you could use to make your retrospectives interesting.

This info is from the "Agile Workshop: Continuous Improvement Through Retrospectives"; session conducted on Dec 15th Wednesday by Sreekanth Tadipatri.

Method 1: Start-Stop-Continue

• Create 3 columns titled Start, Stop and Continue
• Have team members jot down what they would like to stop doing, start doing, and continue doing on 3 different colored Post-Its
• Paste the different colored post-its in the 3 columns

A fun exercise and you've got some learnings too. Remember to pick up only one or two ideas to implement in the next iteration to avoid being overwhelmed.

Method 2: Team as a Boat

• On a chart draw a boat at the center which signifies the team
• Include an Anchor - to signify those risks that weigh the team down, work could come to a standstill if this risk comes to pass. For example:
• Dependent user story not delivered in time
• Product Owner not available for clarification
• Include a Rock - to signify those risks which if they materialize could be a disaster. These could be items that are usually outside the control of the team and require management intervention. However there is a good chance that these risks may not materialize. For example: 
  • Internet downtime
  • High attrition
  • System failure
• Include positive winds - to signify those things that are working well for the team; are the teams strengths that we need to build and nurture
• Include the headwinds - to signify the forces that cause the team to go off course or slow down. For example: 
• Team member not performing to expectation, 
• Team members switching tasks
• Have the team think about these aspects, and paste them around the objects

And you have feedback to inspect and adapt

Method 3: Happy-Sad-Insight-Challenges

• Create 4 quadrants
• Quadrant 1 - Happy smiley - for those things that made the team happy
• Quadrant 2 - Sad smiley - for those things that made the team unhappy
• Quadrant 3 - Bulb - for those incidents that were insightful
• Quadrant 4 - Question mark - for those challenging incidents

Have the team reflect upon these aspects and paste their thoughts and you are on your way to a reflective journey.