Product Manager Exercise: Design a better Automated Teller Machine

Into the course of every product manager’s life falls a “design a better <whatever>” exercise. In fact, I recently stumbled on a site solely dedicated to this appropriately titled ‘Product Management Exercises.’ It was this site, along with a recent news story related ‘You no longer need a card to get cash from nearly every Chase ATM’ that reminded of a time in my past I replied to the following question as part of a hiring-homework process:

How would you design a better ATM?

• How might you define a measurable outcome to track your efforts?
• How might your approach change if you had two weeks to do this versus two months?
• How might you seek early validation (and or phase out) your concepts?

What you’ll see below is how I like to apply design thinking and lean concepts in both startup and enterprise settings … while also smugly demonstrating my powerful ‘senior systems psychic’ capabilities in my conclusions about mobility.

As always, please feel free to critique, complain, and/or contribute ideas along the way.

Step 1 — Understand the Question (Clear Need)

When answering a broad question such as “How would you design a better ATM?,” I like to approach such a request from the angle of “How will we, as a team, iterate through a build-measure-learn process to design a better ATM experience?” as seen in the infographic below, heavily based on an original by the folks over at WTAStudios:

As you can see, I’ve conveniently enumerated the steps in the above graphic a summery shade of green. Now let’s briefly walk through each step in the context of how we go about designing a better ATM experience.

Step 2 — Get the Big Picture (Research & Observe)

While the original question plainly states the “what,” we really cannot move forward until we understand the “who” and “why” behind the request.

For me, this often initiates a variety of research, observation, and communication activities that may include:

• Talking to sales, marketing, customer support, DevOps, UX, and of course customers.
• Searching the customer request backlog and customer support queue for related issues.
• Ingesting industry and technical blogs, books, chat rooms, videos, and UX studies on the topic.
• Visiting clients to spend a day walking a mile in their shoes.
• Checking out what our competitors are up to.
• Exchanging ideas with industry experts.
• Fielding surveys and landing pages.
• Interrogating all available analytics and operational data.

For this exercise, I did speak to several people from a variety of segments and roles, coupled with copious reading of ATM-related blogs, news articles, videos, and press releases.

Step 3 — Sharing is Caring (Insights)

While I generally want to avoid introducing my personal biases into the ideation phase, I’ve also learned that if I don’t publish my research with some structure — at least at a very high level — that busy people and team members may not always ingest what I’ve discovered.

As part of our ATM improvement exploration, I’ve gone ahead and organized my findings along four categories across two general parties of interest.

In a real-life scenario, this is where I would provide the teams and stakeholders I serve relevant metrics, such as several months of data from the following ATM-related analytics of interest:

While I find Confluence a useful tool to surface such findings, I’m also not shy about cutting a video, creating a dashboard, and crafting slide stacks when circumstances dictate.

Step 4 — Brain Storming

At this point of the process I often like to invite a diverse group of individuals such as development team members, designers, support, and such to a ‘Brain Storming’ session where we end up collectively organizing our ideas so they look something like the photo below:

The steps are simple enough:

1. Briefly review key insights from step 3 above.
2. Encourage participants to write down their ideas on individual Post-it® notes and then affix them to the whiteboard. All ideas are valid. Duplicates are fine.
3. Invite the participants to group the ideas as they see fit.
4. Ask the participants to jointly stack-rank the ideas within their respective groups.
5. End with a walk and talk through the ideas, fine-tuning their grouping and ranking as needed.

For the sake of our ATM assignment, we’ll pretend that those engaged in the activity went ahead and organized the ideas in exactly the same categories I presented in my step 3 insights documentation:

Step 5 — Pick a Target for Improvement (Hypothesis)

For this step, I usually propose a hypothesis to key team members and stakeholders, where together we fine tune it so it fits the Lean Startup template of:

Getting back to our design question, I encountered articles that suggest banks want to move their customers away from cards and to their smartphones for a couple of reasons. While the mobile approach helps banks provide faster and more secure ATM transactions, it also serves as a stepping stone to move customers another step closer to the e-wallet experience. Both services, while benefiting the customer, help banks realize significant savings and fee revenue in a variety of areas.

This is why I found it fascinating that twelve out of twelve people were entirely unaware that their banks have been offering them free mobile ATM apps since 2016. Equally intriguing, a few of those interviewed expressed hesitation, even though the smartphone app reduces the number of steps and offers improved security over the card-to-kiosk pattern.

These factors, when combined with our brainstorming, seem to indicate an initial need to understand the current lack of mobile adoption. I think it is important to identify what we’re missing regarding product-to-market fit. In the course of working with the teams and stakeholders I serve, I express this approach in the form of the following measurable and actionable hypothesis:

If the metrics above sound familiar, it is because they are derived from common industry aggregates such as Average Revenue per Daily Active User (ARPDAU) and Customer Profitability Score (CPS).

Step 6 — Understanding the Target Segment (Personas)

Sometimes I roll personas into step 2. Regardless, the important part is to understand the user journeys enough to create personas with which we can empathize and identify.

Here’s a handful of examples relevant to our ATM conversation:

Step 7 — Epics

Crafting the Epics

The folks at Yodiz do a great job at defining an Epic in the Scrum context as “… a big chunk of work that has one common objective. It could be a feature, customer request or business requirement.”

Let’s create epic-level narratives for each of our user types based on their top feature needs.

1. As a software engineer, I like to tap-to-pay, but occasionally I need to visit an ATM in an unfamiliar setting to withdraw cash while traveling.
2. As a food cart vendor, I need to both deposit and withdraw cash fast, from a variety of locations, at all times of day or night depending on the heaviness of customer volume.
3. As a stay-at-home-parent, I generally visit the ATM once a week to deposit checks, check account balances, and withdraw cash to pay allowances or vendors at the farmer’s market.
4. As a hotel manager, while I mostly deal in credit card transactions with our customers, I often need to transfer money between accounts and, from time to time, withdraw cash to keep a certain amount of petty cash on hand. We no longer accept checks.

As you can probably discern from the text in bold above, we have four epics up for consideration that include:

1. Depositing Cash
2. Withdrawing Cash
3. Checking Account Balances
4. Transferring funds

Epic Prioritization

Which ATM-related epic do we start first? Well let’s go ahead and pick four areas of our business that matter, which we’ll score along the following lines:

Next, we measure each of the epics based on the above business scores, with the highest scoring epic becoming our top priority.

Step 8 — Feature Stories & PBIs

Feature Stories

Epics generally require further refinement into logical units or themes usually referred to as ‘Feature Stories’ in the context of Scrum or Kanban.

Here are four such features for our ‘Withdraw Cash’ epic, listed in order of priority:

• Understand our Mobile users, collect preference data.
• Emphasize withdrawals, start counting the costs.
• Optimize on location, our first AI experiment.
• Challenge ATM ad effectiveness, personalize using AI.

At the end of each feature, I want to position the organization with enough data, feedback, and failure to answer the question “Do we persevere in our current direction, or do we pivot?”

Product Backlog Items (PBIs)

We still don’t have enough granularity for our development teams to estimate and plan work effectively. At least not until we break down each feature into ‘doable units of work’ commonly known as Product Backlog Items (PBIs).

I’ll spare you the gory detail of how I set these up, however, if you’re interested in a play-by-play of my approach, then I’d recommend visiting my recent blog post titled: “E is for Estimable — Part 4 of 6 of why it pays to INVEST in your user stories.”

For those not reading my PBI centric post, here’s the TL;DR:

• The User Story — answers the question, “What problem or pain point are we trying to address, and for whom?”
• Description — articulates and aggregates conversations and data describing the problem we’re trying to solve.
• Acceptance Criteria — provides the team with criteria to know when they’re done.

Step 9 — Sprint Planning & Iterations (Build)

With PBIs in place, we can plan. For the sake of our ATM assignment, we’re not going to factor in all the deployment and DevOps complexities that require consideration in an enterprise scale CI/CD release setting, nor am I going to detail a full-blown JIRA backlog.

Instead, below, I offer an over-simplified listing of how our first four iterations might flow, provided the organization is not confronted with a need to pivot. Note, the use of features to define iterations also puts us in a position where we can stop the project at the end of week 2 versus at the end of 2 months.

Step 10 — Measure & Learn

In response to how we would measure outcome, my thought is to collect as many of the metrics as is feasible that we identified and enumerated in step 3, surfacing them in easy to access dashboards.

In response to how we might see early validation, I’d keep a close eye on our AMTPDAU / ACPT metrics, and their contributing analytics, for the following signals after every sprint iteration:

• If we find that the total mobile usage is less than 15% of total ATM usage, then we need to take a step back and see if we don’t have to overcome a marketing and awareness issue.
• If we observe over a 5% loss of mobile adoption, especially when accompanied with either bad Play Store/iTunes reviews and mobile app uninstalls, then we need to consider if we’re only succeeding in antagonizing our mobile user base.
• If faced with a greater than 10% increase in costs outside of development, then we need to investigate further and see if there is a causality between our app and operational costs.
• If in the course of failing forward fast we uncover a new value stream or better market fit, then we need to adjust our plans accordingly. For example, we observe revenue opportunities enjoyed by recommending nearby branch locations and local vendors during the session.

On the other hand, if we find that mobile usage goes up, and costs go down, and app store reviews turn positive, let’s celebrate, and then we double down on our current direction.

Steps 11 & 12 — Rinse & Repeat (New Ideas & Revise)

Every PBI, Feature Story, or Epic in our backlog is subject to change with each iteration. We continue to loop through steps 7 through 10 until we feel we’ve delivered enough value to call things done, or moved in a direction that offers a better product-to-market fit, or agreed to abandon the work.

Finally, not being one to stand on ritual or procedure, I’m always more than glad to reconsider, remove, or rework any of the above steps if they’re not adding value to the teams, customers, and organizations I serve.

Now pardon me while I try and figure out what is going on with my smartphone’s NFC settings.

As you can see, in the end, I didn’t really ‘Design a better ATM’ as much as a ‘Better ATM Experience.’ My thinking at that time being that a smartphone-centric approach was already in the works, it just wasn’t well understood nor adopted.

Feel free to leave your own comments, criticisms, and/or complaints. I’m never 100% about everything, all the more so on such a long-winded blog post!

YMMV