Improve an Existing Product

A core responsibility of a Product Owner is to always be improving and iterating on a product by adding value to it and its users.  If a client asks you how you’d improve an existing product here is a simple framework you could follow.

1. Discuss the product’s objective - keep it high level.
2. Figure out what the product needs to reach its objectives.  Here are a list of questions you’d start with and then drill down from there based on the answers you received.

           a.  What have you noticed about the product on its way to reaching its objective?  What has it been successful or not successful at doing? 

                 i.  Think acquisition funnel = acquisition, activation, retention, revenue, and referral.  

           b.  Does the product seem to have a hard time acquiring or activating users?  Does the product have features that encourage users to stick around for a long time?  Does the product have enough drivers that could incentivize users to convert into paying customers?  Is there a strong reason for the product to have users refer or recommend it to other users? 

3. Brainstorm improvements for these needs.  Which of the needs is the highest priority for the product and come up with ideas using that priority.  Or ask which need the interviewer needs you to focus on.  Explain your own prioritization first.  With ideas for improvements come up with short and long term implementations.  
4. Lay out your execution plan and success criteria.  With each improvement discuss the pros and cons or costs and benefits of each.  Explore how you’d roll out the execution plan in the short, mid, and long term with your improvement ideas and how you’d launch them.  Short = increasing revenue by improving the completion rate of purchases then briefly discuss how you might conduct split tests around the shopping cart experience.  Explain success metrics for each idea, i.e. for shopping cart is a 10% increase in purchase completion.  Additionally you’ll want to list out the metrics you plan to track in order to confirm the success of this improvement.

This is a brief, but effective way to quickly walk a client through how you’d improve a product they need released to the market.

Product Backlog

In a nutshell a product backlog is a prioritized feature list that contains short descriptions of all the functionality desired in that particular feature.  While the PO is in charge of the product backlog not all of the ideas should be flowing from you.  As the PO you’ll be getting ideas from everywhere and it is your responsibility to triage, organize, and prioritize them.  Ideas may come from user feedback, making feature lists around what competitors are doing, or you’ll get feature requests from your own internal teams. 

Users may give ideas to you, but they may not be your customers.  Users may submit ideas via Zendesk tickets, web submission forms, forums like Reddit and others, internal teams/employees or social media.  These submissions may be complaints about the product or processes within it or what they wish they had.  You could build things with word clouds.  

Customers are different from users.  Say your product lies in the educational games arena.  While children are the users the customers end up being the parents buying the product.  

Metrics could also be a way to gather ideas to be added to your product backlog.  This can be any kind of quantitative data that you can get in or from your product.  

It may be important to also list any bugs or any technical work within the backlog.  Prioritizing the list will require consistent communication and interaction with relevant stakeholders so that you are bringing forth the most relevant and valuable features to your product.  

When maintaining a backlog there are many tools you can use, but for those just starting out an easy tool to use is google spreadsheets.  The first column you’d want to add is Date Added.  This will show you when something was added and allow easy sorting for that.  The next column would be Feature Idea Name.  Then after that you’d have the description, i.e. what is overview and desired functionality of this suggested feature. 

If you’re backlog contains a bug there are a few things you’ll want to include when adding it to the backlog.  One you only want one bug report in a story and be sure it has a clear title and proper grammar in the report.  You need simple and repeatable reproduction steps.  Include expected results and observed results.  Screenshots or other pictures of bug in action when user interfaces are involved.  You’ll also want to include the build/version/release where bug was found as not all customers are always on the same release.  

Prioritization criteria will vary by team and company, but it is on the product owner to come to a consensus on how this should look.  Three pretty standard criteria that can be used are impact, urgency, and engineering cost. 

Impact or importance is a way to define in a subjective manner whether or not this particular feature idea would move an important metric.  A high numerical score here using a scale of 1 - 5, with 5 being equal to high importance vs a 1, which would indicate low importance. 

Urgency would be asking the question of how important it is to get this feature out now.  1 being not urgent and 5 being very urgent.  So even though something may be impactful doesn’t necessarily translate into something being urgent.  Maybe users would be saying that something is really affecting their workflow and cutting down on their efficiency and is something that needs to get worked on right away even though this feature might not have the same impact as something else score wise.  

Engineering cost is typically where you’d want to involve someone else, i.e. an engineering manager or a high level developer you’re very close with if you don’t have the technical expertise yourself.  Scoring these stories on a scale of 1 - 5 would have 1 representing something as slow to build (1 month) with 5 being quick to build (1 day). 

Other is another column you could have in your backlog.  There are other potential prioritization criteria to consider outside of the ones already mentioned.  

You’ll want to have a total and status set of columns in your backlog as well.  Total would be a sum of any of the prioritization criteria you gave values to earlier.  Status would detail where the feature is at the moment.  It would include things like whether it needs more definition or to be reviewed even further or to be slotted into a development cycle or sprint.  The target launch date would also be listed in your status column. 

Holding periodic check-ins with relevant stakeholders to prioritize your backlog will ensure you are releasing the most valuable things for them and the company.  

What is a Spec?

A spec is a document that is written to allow people to understand a product’s purpose, functionality, and or features.  It should be comprehensive and understandable so that anyone without any prior context could be able to properly understand the product or feature that is outlined.  A detailed spec won’t solve every possible problem, but it should be written so that you can think through as many possible problems as you can and minimize any surprise situations that could come up.  Once the team starts work you may find that some or many of the things outlined in the spec aren’t able to be implemented and so you need to be flexible for what it will actually turn out to be.

The following is a spec I use in my work as a Product Owner.

Spec Template

Product / Feature Name: What is this product / feature called?

Painting Project Progress

Author Name(s): Who wrote this spec?  

Brock Norton

Team Members: Who are the stakeholders involved in this product / feature? This provides context for other teams reading your spec so they know who they might want to reach out to for further details.

Brock Norton, Renee Norton, Tammy Lasman

Summary / Background:  What is the context of this product / feature? For example, if this is a user-facing product/feature, what is the current situation for your users and at a high level, what will this product / feature functionally do?

This will be a web application that production managers, crew members, and customers can log in to to clock in and out on a specific project,check the progress of a project being completed so that scheduling from the PM and customer standpoint can occur without having to call or text people to see where things are at with the project.

Terminology:  List any terms that you plan to newly introduce with this product / feature. Explain in concise language what these terms mean in relation to this product / feature. If you can avoid it, try not to introduce too many new terms that might confuse other team members.

N/A

Goals: What are the goals of launching this product / feature?

Track project progress for scheduling and customer service purposes.

Success Metrics: How will you be measuring success of this product / feature? You may want to list quantitative / qualitative criteria that you will be evaluating. Every product / feature you release should have some sort of measurable success metric!

Eliminate text or call check ins by painters to production manager and subsequently production manager to customer.  Will be able to see if a project came under/over budget timewise with the customer facing portion and budget wise with the production manager as well as with time budget.

Target Audience: Who are the target users for this product / feature? Provide some context as to what they are currently doing or any existing workflows / behaviors. If you have any existing research on user personas, make sure to include that context here. If you need to make any assumptions about your target audience, make note of that here.

Production managers, crew members, customers.  When a painter is assigned a project they clock in under that project, but it doesn’t give them, the production manager, or the customer, any indication of how far along in the project the crew member is.  If they want to find that out the production manager needs to tally up the hours, compare it to the project’s budget, then update the customer accordingly.  Additionally this updating of roadblocks or impediments may be hard to communicate due to phone tag issues between the crew member, PM, and customer whereas there would be a place within the app to upload a picture or string of text to give a status update on the project or any issues within the project.

Requirements:

#	User Need	User Stories	Launch Phase
1	User needs are one of, if not the most important portion of any product / Feature. Prior to even worrying about your user stories or solutions, you should have clearly defined user needs (remember as a PM, you’re a champion for your users and you should be completely in-tune with the needs that your team is building for!) A user need can follow a template like: needs a way to	User stories are short descriptions of a feature told from the perspective of the user who desires the new Capability. A user story generally follows a template like: As a , I want so that Sometimes, a user story may cover a large amount of functionality. In these cases, these stories may be referred to as ‘epics’ and may need to broken out into individual, smaller user stories.	While it’s important to be thinking of every possible user need /story from the get-go, the reality of development is that without unlimited resources, you’ll generally be time-boxed and therefore will need to prioritize which user stories are important for an initial MVP launch vs. a V2 launch. This column section will specify which phase this story should launch in.
2	Crew member/production manager/customer needs a way to quickly and easily see how long till a project is completed for scheduling purposes.	As a crew member, I want to see what my hours for the day did to impact the overall progress on the project so that I can see if I’m over or under budget to earn bonuses for coming under budget on a project.	MVP
3	needs a way to	As a production manager, I want to see end of day progress on a project and any comments on issues for the day so that I can resolve issues and update the customer if needed without having to play phone tag via call or text with the crew member to gather said information.	MVP
4		As a customer, I want to log in to the app to see how far along the project is to being completed so that I can plan for my next project, vacation, family visiting, etc.	MVP

User Story Details:

1. User Story

As mentioned in the previous section, sometimes a user story may cover a large

amount of functionality. In these cases, these stories may be referred to as ‘epics’ and may need to broken out into individual, smaller user stories.

You may want to include this details section so that you can take the time to provide any extra context / details for the user story and/or use this section to break the epic into smaller individual stories.

Along with the extra context / details, you can also include “user story conditions” that explain scenarios you want to ensure the user story is covering. For example, if your user story was “As a user, I want a credit card drop-down option so that I can select which credit card I want to pay with,” then you might have user story conditions that say something like: “The credit card drop-down options should include: Amex,Mastercard, Visa.”

Additionally, you may want to include any screenshots / wireframes / design

presentations that can help provide visual context for the user story. This helps guide the reader into better understanding the functional use of this particular story.

User can log in via Facebook, twitter, or google.

      2.  User Story

Write details about User Story 2.

Crew member can clock in and out on a project where the production manager has set the hours budgeted for a project.

      3.  User Story

            Write details about User Story 3.

           

Customer can login to see project progress at the end of each day.

Designs: If you plan on handing off this spec for a designer, you’ll want to consider adding a timeline of what deliverables you expect to receive from the designer. If you have final designs / prototype already for the product / feature, feel free to include or link to them in this section.

Sprint one design should have wireframing and prototype design completed.  Web portal design should be completed by sprint two.

Legal: If there are any potential legal issues / implications, you’ll want to include any relevant context / details in this section. I.e. perhaps your product / feature involves collecting sensitive user data and your legal team has specified that this data needs to be held on record in a database for a minimum time period.

N/A

Launch / Roll-Out Plan & Timeline: What are the logistics and timeline of this launch? You may want to have a separate launch checklist that you link to in this section. If you only plan to roll-out this product / feature to a select group of users, make sure to detail that in this section.

One month from initial sprint planning all wireframing, prototyping should be completed.  Users should be able to login to clock in and out during this initial sprint.  Sprint two should have the ability for the production manager to set the hours on a project and crew members can clock in and out on said project.  Sprint three will have a spot for the crew member to add comments or pictures of issues on the project.

Agile Method: Kanban

As I've discussed on this blog some of the intricacies of Scrum in an agile environment I thought I'd also touch briefly on what Kanban is as it pertains to an agile environment.

For starters typically a Kanban board is made up of three columns as seen below.

Instead of having a product backlog and a sprint backlog like you would see in a scrum agile environment in Kanban you only have one backlog for the product and it occupies the whole of To Do on the Kanban board.  As with scrum the very top item in the product backlog is the most relevant/highest value item to work on next on down the list to the bottom.  The next available dev team member will just take the next available item and work on it until it is complete at which point they'll then move it over to the Done column.

Kanban is also unique in that it doesn't utilize sprints to complete the work, i.e. there isn't a one to four week time frame for which the work in the To Do column must be completed.  While it may seem like there'd never be a break from the action teams can implement certain constraints to the board, i.e. only 2-3 items in the To Do or In Progress columns at a time.

One other benefit to utilizing Kanban is that there aren't a lot of meetings as it pertains to sprint planning, sprint review, and daily stand ups.  Also it works well for teams that don't want to do a lot of costing or estimating of each individual item so that they're having to figure out exactly when something will be released and in which sprint.  The drawback to that of course is that you then may not know close to when something will be released.

And there you have it.  A quick touch on what Kanban is.  What do you think?  What do you do differently on your team?

Questions I ask to get up to speed on a new scrum team as a product owner or a scrum master Part 2

Welcome to part two of this series on questions I’d ask during hour one of meeting with the team to get up to speed on what they’re working on and how I could help or see where I know I could help.

1.      What is a typical distribution of story sizes in your sprint backlogs?  

This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.  Clearly actionable stories to start the sprint should always be ready with others that can be moved up to be worked when the first ones are finished.

2.      Are you re-estimating user stories at the end of a sprint? 

If so, under which circumstances are you doing so? That should always be done if a user stories turns out to be way off its original estimation.  The PO should update the stakeholder accordingly so they’re aware of the changes/delays in the project.

3.      What was your velocity of the last three sprints?  

The team should know its velocity, how could it otherwise possibly improve?  If you can’t measure it, you can’t improve it.

4.      How many user stories are typically not finished within a sprint and for what reasons?  

If the team is bullish and picked more user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively affect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern that needs be resolved asap or at the very least the next backlog grooming session.

5.      Are you changing user stories once they become an item of a sprint backlog? 

If so, under what circumstances are you changing the user stories? Making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers value. Making it larger after the sprint planning is, however, not acceptable.  If they’re being made larger perhaps breaking it out into two stories would be better.

6.      What are the obstacles the team is facing today?  

If they’re systematic what ideas/tools/additional personnel brought on could be done to remove them?

7.      What are the dependencies on other teams?  

And if there are dependencies, are you waiting for other teams to complete their tasks?  

8.      Define and discuss at least two or three key team goals for the project.  

Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the team initially. It can help the SM or PO understand team motivations and dynamics.

9.      What are key success factors (KPI’s) to achieve our team goals?  

Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues which the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.

10.  What do team members hope to achieve with this project?  

I like to get a sense of people’s personal goals for the project in addition to the team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance agile team, or have other goals.

11.  What type of work environment do we want to create on this project?  

This question can stimulate good discussion about how team members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.  If there are differences that need mending then a group setting may not be the best place to resolve said differences. 

12.  What can we do as a team to make sure that we support each other to achieve our team goals?  

This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, to take on roles outside their specialty, and trust their team when they need to ask for help.  Often there are senior or tenured people on a team mixed with newcomers that would love some mentorship and coaching.  Making this a regular goal helps elevate team cohesion, morale, and job satisfaction.

13.  What should we do when we are not achieving our goals or not supporting each other?  

Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.  Adding an impediment column to your workflow might also help the team feel and see that though work has occurred that just because it is stalled isn’t their fault.  Sometimes defects just need time outside of the team to be resolved and having that column could help in your workflow and planning.

14.  How should we celebrate success for achieving our goals?  

It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards.  While monetary rewards can be nice, if you worked any amount of time you know other types of recognition often are more valuable intrinsically to a team and its members.

15.  Who are the domain experts outside of our team?

This is useful to establish who to talk to when a story comes to an impasse, but perhaps an official designee for resolving said impasse hasn’t been identified who could resolve the issue.