Posts Tagged ‘Customers’

This is by far the most dramatic book I’ve read on customer retention, but I really enjoyed it.

Even though the book is over 20 years old, the majority of content and principles are not only still relevant when it comes to customer service and customer experience for digital products, but also when collaborating with stakeholders as the book touches on the importance of telling people who have a problem to solve that you understand how they feel, empathising, listening…

I particularly enjoyed reading about Jeffrey Gitomer’s personal stories/learning experiences and the last chapter ‘Lessons you never learned in school (are the ones you need to succeed)’ is pure gold, full of practical tips on self-development which was totally unexpected.

“Satisfied customers will shop anyplace. Loyal customers will fight before they switch – and they proactively refer people to buy from you.”

“The CEO, or owner of your company does not pay you…the customer pays you.”

“No matter how much people pay, they expect a quality product. If you’re selling price and sacrificing quality, eventually you will lose the business to someone with opposite thinking.”

“The biggest reason that positive endings don’t happen is because employees are trained in policies and rules, rather than principles.”

“If you take ownership of the problems, you take ownership of the customer. If you let them go away, someone else is sure to take care of them that day – and for days beyond.”

On schooling..”I’m recommending we supplement the stuff that makes us excellent Trivial Pursuit and Jeopardy players (Geography, Literature, History), for the information and lessons we could really use (Attitude, Goals, Responsibility).”

“If these characteristics of successful people seem so simple, how come they’re so difficult to master? Answer: your lack of personal self-discipline and a dedication to life-long learning.”

A practical short read on how to properly talk to customers and learn from them by Rob Fitz.

Whilst the book focuses on validating new product/business ideas, many principles Rob talks about still apply to existing products, enabling you to understand how and why customers are using the product in the way they are and how they feel about the product vs. competitors – building up qualitative data about the UX.

Even though the book was published 8 years ago, it’s still relevant and I loved how the book focuses on having an informal chat with customers about their feelings and why first, before diving into getting feedback on solutions which you’d do in future conversations – how can you satisfy customers if you don’t understand them first. Also, with remote customer interview tools now available like User Zoom, Lookback and User Testing, it makes it easier more than ever to talk to customers weekly.

The Mom Test:

1. Talk about their life (or how/why they use the product in the way they do) instead of your idea
2. Ask about specifics in the past instead of generics or opinions about the future
3. Talk less and listen more

It’s called The Mom Test because it leads to questions that even your parents can’t lie to you about.

Link here to the book on Amazon.

It’s also a great companion to Lean Customer Development by Cindy Alvarez.

Idea

Getting an idea (problem) to customers (solution) is a complex cycle no matter what organisation you work in, but constantly monitoring and optimising the whole cycle will make it as smooth and efficient as possible improving the ROI for product iterations.

Irrelevant of the size of the problem that you’re looking to solve, it’s still important to firstly understand the value of the problem – why does it need to be discussed any further let alone hit the development teams for rough sizing? Unless you have data or a solid rationale to specify the size of the problem or opportunity, it simply shouldn’t go any further than the analysis stage. Not only is the value crucial for prioritisation, but it’s also important for the development team to know the benefit of working on the PBI (Product Backlog Item).

Once you’re confident the problem is worth solving, then it’s time to set the priority by weighing up the opportunity with all other PBIs and having a gut feel on size is totally acceptable at this stage to avoid draining the development team time with every single idea and talking about work, rather than progressing with solving high priority problems.

Before the feature touches a team for grooming it’s important for Product, Delivery and Technical to collaborate on how much resource gets assigned to solving the problem or phase eg. One team, two teams or all teams – depending on the option could impact in flight features and efficiency, so it’s important to collaborate over different delivery scenarios before rushing into a decision just because a deadline looms, as getting more teams onto a problem to solve could make the delivery go slower and impact efficiency unnecessarily.

Getting a PBI / Feature from idea to a ‘ready‘ state for development stage takes a significant amount of grooming which involves the Product Manager, Development Team and Technical Architect all of which is vital to ensure that when development starts that the right problem is going to get solved in the right way, rather than anyone wondering during development what problem they’re solving, what the value is or having to do loads of rework further down the line. This is one of most important parts of the delivery phases with the key elements being:

  • Solid ‘As a’, ‘I want’, ‘So that’ description which should give a crystal clear indication of who wants what and why
  • ‘Value’ of the problem
  • Acceptance Criteria of the requirement
  • Background / context which could be a link to Confluence which shows ‘As Is’ and ‘To Be’ flows / UX and can be used as part of a kick of for the feature to the development team
  • Any dependencies
  • Notes from the team working with the Technical Architect on any up front technical designs

When the PBI is in a ‘Ready’ state and prioritised high enough, then it goes into development whether that’s in a Sprint if it’s Scrum or on a Kanban board. The ‘in development’ phase gives you the most opportunity to improve efficiency / throughput and the Scrum Master is key to help the team achieve this (continuous improvements) whether it’s helping unblock impediments, coordinate with other development product lines or suggesting ways of getting PBIs over the line. There’s no harm also in hiring a Scrum Master for a team using Kanban, as ultimately the Scrum Master role is to help / support the team progress and the things which a Scrum Master would help out a team for Scrum would also apply to Kanban eg. Chasing down impediments, coordinating dependencies, removing blockers and working with the Product Manager on improving the quality of the Product Backlog.

Delivery

Once the ‘Definition of Done‘ (DoD) has been met including demo approved, it’s time to ship the product iteration to customers. Believe it or not, after all the work that happens prior to this, the release process is the part that could get stuck for weeks depending on the architecture and how the release process is monitored for Scrum (as often it’s outside of the DoD), but again this is where the Scrum Master can really step in to add value coordinating with release managers, but also suggesting release, environment and pipeline improvements to the development team and PO by reviewing delivery KPIs. For Kanban, tracking the release process is much easier as every process up to live gets incorporated on the Kanban board as there’s no set time boundary aka sprint.

Lastly it’s time to go back to step 1 (the analysis phase) and iterating based on how customers use the latest product iteration.

Like I said at the start, the Idea to Customer cycle is complex and involves a lot of people, but monitoring, testing out other agile frameworks and optimising the phases within the whole cycle will yield in a higher & quality throughput of features getting delivered to customers, so it’s important that the people responsible for Product, Delivery and Technical collaborate closely having this high up on their agenda and regularly communicate to the business the fantastic efficiency improvements which have happened recently and what’s up next to optimise.