Jonathon Arnold

This Is Product Management: Collaborating with Agencies

2018-11-09T12:15:30+00:00

Recently the awesome folks at Alpha invited me to speak on their podcast, This Is Product Management. I’m a longtime listener of this show, finding it full of insights and tactics for the modern PM. I was just delighted to add my voice to the show.

The episode is titled, Collaborating with Agencies is Product Management. I’m really fortunate to have worked with some incredible agency teams, both on the agency side and as a client. In this episode, I break down strategies for planning, collaborating, and improving working relationships with agency partners.

Have a listen over at their site or at this embed:

Three Quotes About Creation

2018-09-13T12:15:30+00:00

Here’s three quick quotes about the creative problem solving process. I find myself returning to these time and again when it comes to making things people use.

On Problem Definition

A problem well stated is a problem half-solved. — Charles Kettering

This quote is used to defend the value of strategic alignment. Define your problem, frame up the need, and it’s much easier to be creative about an appropriate solution. Otherwise, every attempt you take at solving the problem will equate to stabs in the dark. You might hit your target, but without clearly stated goals, who could say?

Forget thinking outside the box; think inside the strategic frame. A good strategic frame has:

Clear benefit, to a…
Clearly defined user, with…
Clear outcomes for the future.

Without knowing these things, you have no frame to play within. Without the frame, you don’t have shared perspective with others on your team.

On Customer Needs

If I had asked people what they wanted, they would have said faster horses. — Henry Ford

First off, it’s worth stating that Ford probably didn’t say this, but it’s fun to think he did.

I hear this quote a lot inside the walls of the corporate enterprise. It’s used to dissuade against UX research, especially talking to customers and users of a product or system. The underlying bias is, I know the problem better than my users do, and I can solve it better than they can. This is a thinking trap.

That said, I state the quote right back: we do want to hear about the faster horse. We help them imagine, describe, and draw the horse. We We empathize with our users to understand why they need a faster horse. We look at the current constraints to understand why it’s logical for our users to want it. (It’s easy to want a new horse when you own a barn, a carriage, and the roads are purpose-built for your horse to traverse)

Then, we go design a car. We do this to exceed customer expectations, but we can only exceed them if we know what they are in the first place.

I love the Kano model for this. The Kano model of prioritization sorts ideas into three distinct areas:

Unstated expectations: table stakes items that are only talked about when they aren’t present (there’s nowhere to sit on this thing!)
Stated expectations: requested, vocalized items from our user (I want to go faster!)
Delight: unstated, unknown items that a user would love, if they only knew about it (my Model T is so much more reliable than my horse and buggy!)

To be clear, you can’t serve up delight if you don’t meet both sets of expectations along the way. It’s a tricky balance, but only comes from understanding your user on a deep level.

On Understanding Users

The secret of my success is a two word answer: Know people. — Harvey S. Firestone

First things first, I’m proud to be a small part of the legacy of this quote. I work for Bridgestone Retail Operations, which proudly runs the Firestone retail business and sells tires bearing his name every day. Now, that aside…

Knowing people means you understand their motivation and needs. That means you can help them overcome their problems, which means you’re valuable to them. Simple enough!

When we make things that we know people need, with a validated and real problem, good things happen. We might not make the next unicorn company or change the world, but we might just change some aspect of life for someone. Isn’t that amazing?

Product Management Pitfalls

2018-05-01T16:15:30+00:00

In my time as a product manager, I’ve found myself in a variety of situations that some of the best minds in product management have long warned about. I’ve tried to make the most of these situations, even if what transpired wasn’t the best possible outcome. They’re called pitfalls for a reason: it’s easy to get caught up in doing what seems right, only to wind up dealing with the fallout and entanglement of your best intentions. Simple product management mistakes often have long term ramifications, or just take a long time to undo. Before you find yourself stuck in these traps, I hope these points help you do better for your teams and your products.

Note: I can’t take credit for many original ideas here, and can certainly identify references for most of them. To that end, there’s some recommended reading at the end of this post.

Timing the Roadmap

There’s two schools of thought with a product roadmap: include timelines on your roadmap, and don’t include them. I firmly fall in the “no timelines” camp, for a key reason: a product roadmap is not a project plan. Projects have identified scope, budget, outcomes, and estimated timelines. A product roadmap can include aspects of these (especially problem/scope identification and key outcomes to influence), but shouldn’t be a list of hard and fast initiatives with due dates. A good product manager should work with a project delivery team to shore up all these elements and build project plans and backlogs, when necessary, but that’s not the same thing as the roadmap proper.

Within a very short period of time, a product manager who commits to providing timelines will find themselves answering questions like, “When will that feature be out?” instead of asked to measure problem opportunity and value. The role of the product manager will morph into pushing the team to deliver on a set date, rather than toward a set outcome. Achieving business outcomes are always more valuable than specific dates. (But yes, an outcome may sometimes require hitting a particular date — more on that below)

I find that roadmapping tools like ProdPad provide a great platform to measure user need/impact, business value, and priorities. Aha! allows for specific quarters and actual dates - be careful there. I much prefer the ProdPad method or a rough sorting of priorities in team, like Now, Next, Near, and Horizon. A product manager can use these labels to show a team’s current focus, and update on priorities to leadership, without having to commit the entire team to a specific due date.

Commitments

On that note, it’s worth reiterating: make NO commitments for the team without involving the team in the decision. A product manager may find themselves in discovery sessions, client meetings, or executive summits, and be asked to deliver a particular feature or functionality, or to have something done by a particular date. You, alongside your counterparts in technology and project management, will have to play a defensive role to protect your team. Personally, I’ve found myself in more then a few awkward moments when I won’t commit to something and slow down the momentum of a productive client or stakeholder encounter. It’s worth suffering these difficult moments to prevent weeks or months of pain.

How should this commitment work? Include the team! Invite as many as possible to discovery sessions or workshops. Hold round table requirements review sessions, and work with them on a comfortable form of estimating (spoiler: no estimation process is perfect). Work with project management to appropriately pad all estimates for error, and include for planning, design, copy, QA, marketing and training. Only then can you provide solid dates and milestones to your stakeholders, and only then can they see just how much goes into every project your team embarks upon.

Crunch Time

If your team has committed themselves to completing a project by a certain time, and realizes extra effort is needed, you can choose a crunch time window or two to get things done. Crunch time is a short term thing, and should rarely be deployed. This is typically a bloated sprint with extra work, requiring longer hours, weekend work, or even an offsite retreat together to get the work done together. I hope it’s clear that “together” also includes product management and any leadership affiliated with the crunch time project: you should be invested, too. When getting into crunch time, have clear expectations of the goal, the time requirements, and allow as much volunteering as possible. When getting out of crunch time, hold a post-mortem session to talk about what happened, and how the team can work to avoid or make the most of crunch time in the future.

This is not meant to be a sustainable working pace, but something your team might only do once or twice per year, if that. Once your team has made it past this crunch time window, expect a similar but opposite decompression period where work output is decreased and productivity or time working is reduced. Your team will need time to balance out the extra work they’ve put in. If you don’t allow for this, or you continually push for crunch time month after month, you will burn people out and they’ll either leave, or worse — they’ll stay and become bitter or unproductive. Their work output will almost certainly be subpar and their attitude may turn toxic. Sadly, this is not their fault, but a result of pushing the team to constantly hit artificial deadlines or due dates.

Decision Making

As your team chooses what to work on next, refer back to your prioritized roadmap often (and don’t change priorities more than once a quarter). Repeat yourself in terms of these priorities — become annoying in your sameness of your priorities. Your team can only work on a handful of things at a time, and that includes planning, ideating, and estimating. Leadership and the business needs to be comfortable with certain things sitting on ice. You should limit your focus as well, and spend time researching, talking to users, and writing towad your priorities.

When building a roadmap, brief, or spec, I’m a believer in the phrase, “Strong Opinions Weakly Held”. Use your experience, insights, and research to stand up confident plans to that future world of what your product should be. In this confident stance, a good product manager holds a few things in mind:

Strong Opinions, But…

The “Weakly Held” part of the phrase means you’ll quickly change decisions, specs, or requirements when presented with compelling data, evidence or just good sense. You have to make sure your team knows this, or else you’ll find them following along with your plan but quietly disagreeing with its tenets. Make sure your team is well aware they can make your plans better, and that they are just as responsible as you are for the successful outcomes you’re driving toward.

Decentralize Decision Making

Not every decision needs to run through the hands of the product manager. Push them to think about outcomes, not specific actions, and release them to do what they do best. The team is smart, subject matter experts and can go off and figure things out without you. Give feedback when they delay because you weren’t around to approve a small but logically solid change. Otherwise, you will become a bottleneck to the creative process, and you will limit the creative potential of the members of your team. Just ensure they remain focused on priorities and goals, and they’ll help you get there.

Comfortable with Uncertainty

As a product manager, your job is to measure the business value and the user need, and express these problems and goals to your delivery teams. With these three disparate areas intersecting, you will be wrong. Often. You need to learn to be comfortable in this wrongness, and learn to pivot toward correct thinking. It’s ok to be wrong, as long as the team knows your intent and is there to help move to the right place together.

Similarly, your team needs to be comfortable with this uncertainty. Your spec may not be intensely detailed. You may not have completed all the research you’d have liked to. The team should be comfortable knowing that you haven’t figured it all out yet, and should get excited with the gaps they get to fill in along the way. Encourage them to participate (not just in planning a sprint or a list of dev tasks, but planning how to achieve your goals) and watch their investment in the product grow.

Going Forward

I’ve touched on just a few tactics and issues faced in the role of product management, but they’ve all got common touchpoints. Every day, the product manager spends time moving the product, the team, and the business forward. There’s always room for improvement in decision making, process, and people skills. I hope you’ll find this useful as you tackle these issues and grow in your role and in your company.

The Dungeon Manager

2016-10-10T10:25:30+00:00

Note: This article was originally posted on Medium. Check it out there, if you want!

I love games. It’s proven that games help our psychological state, encourage social connectivity, and generally relieve stress. Much has been written about the effect of games in our lives, including some truly insightful work by game designer Jane McGonigal.

Games combine the powerful forces of story and play to convey emotion, entertain, and can even teach new skills. Adding game mechanics like achievement, collection, socializing and discovery gives games their unique attributes and appeal — simply called gameplay.

New products apply gamification liberally as a key stategy. Gamification is a cliché, sure, but when done well users are able to engage with powerful mechanics. Profile completeness, points and badges are just the beginning — even the network effect has its roots in game mechanics.

The Dungeon Master holding court.

Classic tabletop strategy games like Dungeons & Dragons have used these same concepts for decades. A dungeon master (or game master) assembles a group and creates a living story — called a campaign — for their players to explore.

The game master is charged with:

Creating a rich world that supports the campaign
Guiding the players in ways that align with their unique character skills
Obeying and interpreting the rules of the game

…and also providing snacks. Overall, the game master exists to facilitate the story and achieve these goals in engaging, creative ways.

Product Management as World Building

Product managers can apply game mechanics to the work of product development, but more importantly they can apply the goals of a game master to the work they do each day.

A product is a created world. It has characters, pitfalls to avoid, challenges to overcome, and a story to complete. By using these game master strategies, a product team can build amazing things and have fun while doing it.

Macro Arc, Micro Arcs

The Adventure Zone podcast has redefined tabletop storytelling in podcast form.

Griffin McElroy, host of the The Adventure Zone podcast, laid out this concept when explaining his rationale and inspiration behind their game. When he wrote their campaign, he focused solely on the overall campaign arc. He knew that the “macro-arc” of the story had to be intact in order for it to make sense. The payoff at the end meant certain key elements of the story had to happen, or else the game was over.

When writing the campaign, Griffin was less concerned with the small, micro-arcs within the story. There are many of them, and there’s too many to script out or rely on in order to keep the game moving. Rather, he exposes various possible edges of these micro-arcs to his players and allows them to explore at their will.

Product Vision

Like a game master, a product manager has to understand the vision and arc of a product. A few key questions to ask:

Where must the product go in the future to be successful?
What market forces (competitors, clients, etc) are at work that must be overcome?
How will it best serve key users?
How will the product change the world in six years?
Most importantly, what does the team and company unwaveringly believe in?

These questions should establish the guide rails the team needs when building the product. Outside of these factors (which may not change quickly or at all!), be flexible to new ideas and features of a product.

Open World

Skyrim actually procedurally generates infinite new side quests.

In an open world game, the playable character is presented with big objectives and lots of side quests. It’s up to the player to choose which way to go and which quests to complete or ignore.

As a result, there may be whole components of a story that go unnoticed by players. A game master shouldn’t hold these plot points as precious, but let them go in service of the greater story being experienced by the players.

A game master has to prepare possible paths inside the story and hold playable characters responsible for interacting with them. The players are a key variable in the storytelling process, who provide new story elements that a game master has to react to.

User Appropriation

When a product gets into the hands of actual users, unexpected things tend to happen. Users may find a feature confusing, or they may even use it differently than it was designed. Of course, a team may release a feature that no one uses.

During these moments, a product team could choose to be hostile towards users and mock them for their misuse. They could champion the features they worked so hard on, and force a user to engage with the feature. This happens often through marketing efforts, re-routing users to certain pages and even redesigning other features so they include the underused new functionality.

Instead, a product team should listen to what their users are saying, watch what they’re doing, and make refinements that enable the appropriated behaviors and actions. Product managers are in service of the product, which is in service to the user. Treat user feedback as gold, and incorporate it as a key component of planning the product’s future.

Here Be Dragons

Here Be Dragons just meant “unknown” on the map, not necessarily danger.

A game master knows what information to reveal to their players.

Sharing information is vital: players have to find clues in order to make decisions. However, knowing too much enables a player to avoid risky situations (and thus, spoils the fun).

Friends at the Table does this masterfully. They share maps with Roll20 to create a remote tabletop experience. Maps grow, iterate over in-game generations, and aren’t ever complete.

Draw maps, but leave blank spaces.#FriendsAtTheTable
— FatT Wisdom (@FatT_Wisdom) October 2, 2016

Friends at the Table Wisdom.

The game master, Austin Walker, is obsessed with clocks. Clocks are little game markers that count up or down, and the hands on the clocks get moved when major actions happen in the game. These clocks are tense reminders that small actions taken by the players have potentially huge repercussions later down the road.

Iterative Design

Leave space in the product. Navigation, page layouts, and text/content will change as a product team learns and builds more. Leave space for the product to grow and expand. If there’s no more space, consider breaking out the product into companion applications.

The first released version of a feature should exist to answer three questions:

Does it solve an actual problem?
Can our users actually use it?
What should we add to the feature now?

Every feature has a roadmap. It grows and evolves over time, especially in response to these questions. A product team should make plans to create more value and complexity in a feature accordingly. However, the first release (or even just usability tests) of a feature can inform it further for the future. Don’t get too hung up on future plans, but leave space in the roadmap and the product for the plans to unfold.

Leveling Up

A Dungeons & Dragons Character Sheet

Playable characters receive experience points (XP) upon completing certain quest elements or defeating enemies. They learn new spells, pick up helpful items, and activate effects over time.

At key XP levels, users gain levels which improve their overall abilities and characteristics. As the campaign progresses, the challenges the players face becomes more difficult. These two forces must be in balance for the game to be enjoyable. No one likes an impossible challenge, but a game that’s too easy to beat won’t be fun to play for long.

User Onboarding

A good product should guide a user through the act of using it. Using tools like Intercom’s Campaigns easily allow a product to “speak” to a user as they take necessary steps to engage with the product.

As a user engages with a product, what are new features or new messages that can be delivered to them? Is it possible to sequence a user’s actions by adding more complexity and additional features once they “unlock” them with their own experience?

Pay walls are easy ways to achieve this, in the SaaS world. Test a “pro” tier model that locks up key features or additional services per month, and segment different audience groups by what they’re willing to pay. These passionate users may have different needs from a free or lower priced tier, which allows a product team to better prioritize a roadmap.

Non-Playable Characters

NPCs act as signposts and delivery mechanisms to guide the player.

Non-Playable Characters (NPCs) are characters played by the game master. They’re more than just exposition or set-dressing: they help move the story, guide the players, and include all enemies the players encounter during their campaign.

A good NPC doesn’t solve the problem for the players, but helps them discover the solution. They may provide a valuable resource or item in a moment of need, or even just raise a flag to point in a new direction.

Humanizing the Product

Tools like Intercom, HubSpot and chatbots are quickly introducing a human element into the onboarding and engagement activities of modern products. Bots and messengers can help provide in-app signage, guideposts and helpful tips to users. They shouldn’t replace a human interaction, but can do wonders for helping remove roadblocks for users.

These bots can easily turn sideways if the interactions aren’t planned properly. They should be directional, helpful, and include an escalation path to real humans.

Steal from Everywhere

Luke, use a constitution saving throw!

Inspiration is all around. While Dungeons & Dragons has inspired many games (looking at you, Skyrim!), storylines within campaigns can contain elements from all sorts of cultural touchpoints. Great campaigns incorporate real-world events, follow the trajectory of movies, books, and more. Look for patterns in story arcs, find things that fit the campaign. Weaving in aspects of amazing stories and ideas only makes a campaign stronger.

No Really: Steal from Everywhere

Inspiration really is all around. Great products and apps launch every day and ideas can come from everyday interactions. Look for patterns, find what works, and find ways to incorporate similar patterns. Don’t copy for the sake of copying, but look for what solves problems that the product is currently struggling with.

And Most Importantly…

Write a story you believe in with people you care about.

Games like this require a team. This can’t be done alone, and if someone isn’t contributing, they tend to get written out of the story. The same is true for building product. Be humble, be helpful, enable others to do great work, and the story will write itself.

RailsConf 2016: Managing Growing Pains

2016-05-25T12:15:30+00:00

I had the pleasure of both attending and speaking at my first RailsConf this year. I gave a talk on how to orient and manage a product team when resources are tight and visions are big. Check it out here:

Natural and Reactive Planning

2015-10-20T12:15:30+00:00

Learn to plan from your brain.

In David Allen’s Getting Things Done, he breaks down how our brain naturally plans a project or task.

It’s a very straightforward process on the surface. Your mind figures out what it wants, then figures out how to get there, then unrolls the plan. Despite it’s simplicity, too often we ignore this instinctual methodology and go it our own way.

Let’s review the way our brain approaches a problem.

Natural Planning

Define purpose and principles (the “why” and the “what”)
Outcome visioning
Brainstorming
Organizing
Identify next actions (a key GTD principle)

The act of outcome visioning has a few simple guidelines:

View the task/project from beyond completion.
Envision and define what “Wild Success!” looks like (without naysaying it)
Capture and document those qualities you imagined

This quickly leads to the large chunks of a project and an established “horizon line” to walk towards.

Brainstorming

When we talk about brainstorming, it’s really more about identifying the right questions to ask rather than ideation. Anyone can come up with creative ideas given the right circumstances. A good brainstorming session frames up the purpose and the desired outcome so the amount of false positives is limited.

Mindmapping is a solid way to handle this task, as it allows for a logical flow to the end of a thought. I really love a tool like Omnigraffle for the job, although MindMeister is a nice web-based option with great mobile and tablet extensions.

When organizing thoughts, identify singular components; prioritize them; and identify the sequence of events. Go deep down each rabbit hole

Reactive Planning

The counterpoint to the natural flow described above is reactive planning. The typical emergency meeting or all-hands council is a good example of this style in action. Allen describes this, too:

A crisis emerges: typically, two unstoppable forces are hurtling steadily towards each other and no one’s made a decision on what to do.

The typical response: “Action! Overtime! More workers!” (Anyone familiar with the Mythical Man Month knows this never ends well)

An all-hands meeting is called and the team lays out their options. They take a step back and start ideating on creative ways to solve the problem. The team starts to panic and thinks about what could happen if those two forces collide. A consultant may be brought in, or a new department head, who holds up their hands, calms the room, and smugly asks: “Wait, wait—what are we actually trying to do here?”

This all-hands meeting to pivotal question is actually the same flow as Natural Planning… but completely reversed.

That last moment of perceived brilliance comprises what strategy truly is: what’s the question no one is asking? What’s the one thing that needs to be said? Identify that and the rest of the pieces will fall neatly in line. Put a name to the principles and outcomes of the issue at hand first and the rest becomes logical and clear — and it’s a lot cheaper and less stressful!

How can you change the conversation and move away from planning out of worried necessity to planning on instinct?

Testing Your Way to a Better Idea

2015-06-15T00:00:00+00:00

In product development, we care about ideas. Ideas create products and services. They connect us to other people. They lead to changing things. When we talk about products, services, people, change, and ideas… we sometimes think about Steve Jobs. He had an uncanny knack for understanding what people would like (and thus what they’d pay for). He also knew how to improve things as technology costs decreased and market penetration increased. He embraced a philosophy of Better.

This is an important word for me (and the Web). The work we do is never done. It can always be improved. The same is true with an idea.

People love stories. They especially love stories they can relate to, or that they can empathize with. If you can understand what the story of your idea is, you can communicate it to a user and convert them to being a part of that story.

###Learning from Listening to People

People are the reason we do what we do. Users. People use our software, buy our products, and sustain our businesses. If we lack empathy for our users, there’s little chance we’ll build something they’ll love. Furthermore, if we don’t listen to them, it’s hard to imagine our relationship improving. One of my favorite examples of creative listening: Lay’s Potato Chips ran a campaign where they reached out to their users and asked them to submit new ideas for chip flavors.

Great idea, as this stable of winners proves. These three are all viable products and their customer base told them so. Letting your users show you the way is ALWAYS a good idea, even if you get some silly suggestions, too:

“Frog?” is my personal favorite.

This is still good news - users making these funny posts made a huge splash on social media, drawing more attention to the campaign. Now, I’m not sure what tools Lays used to manage this campaign but I want to walk you through a scenario of tools you might use when launching a new product. The following process combines a lot of different methodologies

###Identifying Users

If you’re Lay’s, you’ve got a massive captive audience and advertising budget to connect with your audience. What if you’re brand new? You need ways to cheaply and successfully acquire an audience to start experimenting on. These users need to be targeted appropriately and you need to know who they are.

Begin with a persona. Who do you think you want to target? You can start with a rough idea of who this person is and refine over time with the steps we’ll take below.

Recently I’ve been using Personapp to help identify these personas. This tool is a digital version of whiteboard exercise I’ve often facilitated. This app allows you to think through a user’s needs and behaviors, their demographics, and their goals. It’s important to include psychographics, too: breaking down a user’s motivations, interests, values, attitudes and choices.

You should use this tool to create a rough outline of who you’d like to target. This is an evolving concept and your targets will change over time.

Last time we talked about the importance of a verified, evolving idea. We talked about how telling a story about your idea would engage users. Then, we talked about how to brainstorm our target users. Now, we need to take those ideas and thoughts and start applying actual data to them.

####Research Through Ads

The first way to get started is simple: you dangle your line and see who bites. Tim Ferriss, author of the Four Hour Workweek has a killer case study on this. He took his book title—six of them, in fact—and a variety of tag lines. He setup a week long Adwords campaign, spending about $200 in total, and discovered the winning title. With a little bit of market research, he found his product name and value proposition. Not bad.

Knowing what people are interested in about your product speaks volumes. It lets you choose a name, logo and style. It lets you choose a key feature to center around. And if done right, it also helps you learn about your audience. You not only know that clicks happened, but you can learn about who clicked and start to understand who they are.

With Google Adwords and Facebook Insights, you can learn about who’s interested in your idea, where they’re coming from, and what makes them tick. Heck, you might even get to know actual people. Crazy.

####Conversion Testing

Now, you’ll want to know more about these people - that’s where my favorite tool comes in. Optimizely!

Demo time: go visit optimizely.com and see how it works in their sandbox mode.

When you get a user to click on your ad, you’ll want to send them to a well converting landing page. This tool allows you to tweak, test and adjust nearly EVERYTHING on your site without the need to write any code.

On your amazing optimized landing page, you’ll want to capture interested users to an email list. Those folks are going to become very important to you, so make sure you’re using a tailored email solution like Emma or Mailchimp to speak to them in style. Here you’ll give them product news, thank them for signing up and stay in touch… infrequently.

####Surveys

After you’ve grown a small email list, it’s time to engage. Reach out to them with a survey. The easiest place is still SurveyMonkey. You can integrate this with your Mailchimp account and do some really simple, powerful things.

This is a place to further quantify your user. You might know about them from our ad targeting, but you don’t know their specific choices and habits yet.

Ask questions about their potential buying decisions. Why did they find your product interesting? What would THEY like to see the product do? How much would they be willing to pay?

Most importantly, however – you want to ask them for more of their time. Can you speak to them about the product? We’ll get to that more in a second, but this survey should help you identify the main features you want to focus on for your product.

Surveys are powerful tools, but they often rely on what a person wants to say versus their actual behavior. Malcolm Gladwell has some great examples on how people speak about spaghetti sauce and coffee: ultimately, that what people say is sometimes not what they truly believe.

So you get what makes a user tick. You get what they want. …but is it really what they want?

####Interviews

From your organized list of interested users, you can poll 3-5 in a simple interview. A 30 minute phone interview can reveal valuable insights about a user that just looking at data cannot!

Asking open ended interview questions allows the user to guide you through their needs and pain with a current solution. As you go down a path of thinking with the user, you can start to guide them towards an outcome.

To prepare for an interview, assemble a list of 5-7 questions (time will fly!) that you want to ask. I often treat these like therapy sessions: let the user take the conversation where they want it and respond.

I’ll typically use Skype and the Call Record plug-in to capture the recording so I can focus on taking only loose notes as we progress. Don’t forget to tell the user you’re going to record, though!

####Prototyping

The most effective way to show a user your idea is via prototyping.

When we prototype, we mostly start with a whiteboard or hand drawn sketch. We use tools like Flinto or Prototyping on Paper to reveal our ideas in flat, clickable prototypes. Sometimes these are sketches or actual UI. Starting with sketches or lo-fi wireframes allows us to quickly pivot to satisfy a user’s needs. We do lots of different types of exercises (mostly with notecards: ideation, cart sorting, user workflow pathing) to get a users’ ideas articulated.

Notecards are also sort of shaped like screens. We can draw little diagrams that look like apps and guide a user through an experience on the table in front of us. They’re also cheap, portable and easy to play with. You can tear one up when an idea turns sour; it’s cathartic, final and you haven’t wasted time writing good code for a bad idea. I love notecards.

Once we have something to work with, we quickly move into a build phase. Once we’re building, we seek constant user feedback. For prototype feedback, a few tools…

HotJar is a killer resource for these efforts. It combines heat maps, screen recording, funnels, form analytics, and surveys into one toolkit. …and it’s cheap!
Silverback is a Mac app that allows me to record a user’s screen as well as the iSight camera (meaning I can monitor their face/voice as they navigate an experience).
Userzoom is a similar tool, but allows for remote users (meaning they don’t have to be in the room with me).
User Testing is a tool that asks anonymous users (so, not your ideal customer) their thoughts about an app or system.
Feedback Army is another anonymous user tool, but it gives me 10 user responses for $20. Cheap.
Optimizely

Taking this user feedback allows us to start making decisions on how we build. This leads us to our MVP.

The Minimally Viable Product

Often times we use paper prototyping merely as a way to validate an idea or workflow internally or in usability studies. That’s just the beginning: to get close to an MVP, we’ll apply a brand style to our paper or HTML prototypes to create a UI prototype. This concept is clickable and feels like a real experience (especially with tools like Invision or Flinto). It’s perfect for user testing or even to show potential investors or partners.

From there, we can further validate and iterate on an idea until it’s ready to be built. We can ease our way into software development with a front end prototype. This is the first time we’re using HTML, CSS and Javascript to express our idea, but we know that we’re building the right thing. We can now test our assertions for responsive design, identify any holes in the process and create a solid pattern library for all interaction types.

Once we have this in place we can hand the whole piece over to our development team to create the real product. Now, it’s time to ask the key Minimally Viable Product question:

What is the least amount of effort I can expend on creating the most amount of value for my users?

This is a tough question to answer, and it’s why the previously mentioned tools (ESPECIALLY interviews) are important. The concepts and prototypes we’ve created often show the full product experience. Do you truly need all those elements and features to get your product to market?

You should know exactly what your users find valuable and start with only those bare requirements. Using iterative development methods, we can use our user learning to iterate and grow towards our ultimate vision. And now, a little kung fu wisdom:

It’s not the daily increase but daily decrease. Hack away at the unessential. – Bruce Lee

The healthy product is the evolving product. Use your base of committed users to tell you what to do next, and don’t be afraid to pivot when you need to.

All the tools we’ve talked about are important, and they should be returned to frequently. This process is iterative and your target constantly moves. Ultimately, by caring about those you serve and constantly checking up on them, you’ll make a truly meaningful product.

A Non-Profit Discovery Process

2015-04-15T11:15:30+00:00

I love non-profits. Nashville is full of amazing people, doing unbelievable things to help those around them and the world at large. These people are vision minded, with a passion and focus to do something meaningful.

Time and again these same people struggle to brand and market themselves and reach the next level with their efforts. The goal here is simple: better equip, train and support these non-profits to better focus on accomplishing their mission.

Finding the Problems

Every engagement begins with a simple discovery plan to identify capacity needs, efficacy measurements and develop marketing solutions for non-profits. I follow a modified version of the Business Model Generation Lean Canvas, a revolutionary approach to building a business.

Here’s the Non-Profit Canvas.

Problem: What is the unique problem their non-profit is addressing? List 1-3 key things.
Solution: How are they solving it? Try to stay high level with their main mission, not individual tactics.
Unique Value: How are they doing it better than anyone else? What’s their unfair advantage?
Donors: What tools and tactics are they using to engage with donors? Do they offer recurring or sponsorship donations?
Volunteers: What tools and tactics are they using to engage with volunteers?
Campaigns: What are their campaigns focused around, how many are there, and how successful are they?
Metrics: How can we measure success on their solution, donations, volunteerism and campaigns?
Funding: What external funding, grants or foundations are they receiving support from? Do they sell products or services that support the organization?
Expenses: What are their main operational or capital expenses? Are they operating at a loss?

This allows us to unpack all operational and marketing aspects of a non-profit organization in order to identify holes or areas of improvement. This should help us understand the what, the who and most importantly, the why of a non-profit.

This canvas quickly lays out the value, services and revenue sources (and expenses) for an organization. We spend time with a non-profit identifying their core mission, donation/income sources, volunteer opportunities, and an overview of where their expenses come from.

Finding the Solution

Put this on a whiteboard or in front of the non-profit during a casual meeting. Use this as a simple rubric for brainstorming, laying out needs, and identifying their current model. You’ll identify holes — mostly financial gaps, unfortunately — that can be filled. Normally when this canvas is filled out, at least 2-3 major opportunities present themselves really clearly.

The common issues are:

Lack of recurring donations
Lack of attention/volunteerism
Lack of marketing automation tools and constituent relationship management (CRM) software
Operating at a loss(!)
They don’t know the right “ask” to put in front of their audience

Every non-profit needs to…

Inspire with their message.
Educate others about their cause.
Encourage others to give.
Explain how others can act.

Every organization’s mission and message should touch on those points. Their calls to action should be specific, actionable and measurable. Not just “Support our cause!” but “By giving $15 today, you’ll help us educate 3 kids in need this year.”

Some Deliverables…

Based upon the discovery process, there are usually several opportunities to engage with an audience. Many are operational, many are fundraising specific, but all touch on the need for better audience engagement.

Organizations need a viral loop to find the right audience members and engage with them throughout a relationship life cycle. A possible plan to implement change follows four steps, called the Four C’s:

Curate.

By finding the right audience, we know our time is being spent effectively.

Market research
Data mining and analytics
Site monitoring and conversion optimization
Social and content strategy audit

Connect.

Once we’ve chosen our targets, we reach out via a variety of tools (ranging from a wide online campaign to an individual development touch). During this stage it’s appropriate to ask for some level of engagement, be it a donation or just to learn more about the organization.

Email marketing
Social media
Video content
Collateral, mailers and pamphlets
Presentations and event marketing

Cultivate.

We’ve already asked our user base to engage, but here’s the time when we can circle back and make it count.

CRM / drip marketing
Content marketing
Social media engagement
Followup communication / marketing automation

Convert.

At this point, we’ve engaged a variety of audience types in a number of ways. We’re working on narrowing the funnel for a non-profit—persuading our audiences to give in a way that just makes sense to them.

Individual donor asks / visits
CRM / drip marketing second phase
Donation form optimization
Online campaigns & landing pages

The Weekly Review

2014-05-03T16:45:30+00:00

The Weekly Review

…or checking on your checklists

When people think about productivity, they often think about what’s next to do on their task list. What can get overlooked is actually the most important part of a productivity workflow: the weekly review.

Getting a chance to step back and review once a week is vital for understanding where you’re going, what you’re actually doing every day, and what’s left to be done towards your goals. David Allen’s Getting Things Done system lays out a low-stress, high-output review cycle.

Allen breaks out your priorities into six levels:

Runway - Current Actions
10,000 feet - Current Projects
20,000 feet - Areas of Responsibility
30,000 feet - 1-2 Year Goals
40,000 feet - 3-5 Year Goals
50,000 feet - Life Goals

You should evaluate everything 20,000 feet and above a few times a year. These are perfect things to do around the holidays, during quarterly business cycles, or even on vacation. I used a recent vacation to completely change my life for the better by following this system and breaking the tedium of checking off unimportant tasks day by day.

For our purposes, Current Actions and Current Projects are small enough to be looked in on once a week.

Performing a Review

To begin, you’ll want to…

GATHER

Loose Papers and Materials
Your Inboxes and Process them to Zero
Any “Open Loops” in your head (including new ideas, nagging thoughts, and “I should” reminders)

REVIEW

Your calendar (past and future)
Your Task List (completed and open)
Your Idea/Swipe File and any Projects on Hold
Your Major Projects Statuses

IDENTIFY

Collect everything you’ve just gathered into a single system (take photos of paper, organize into a to-do list or Evernote, etc)
Identify what needs to happen before your upcoming events and milestones (what has a due date?)
Ruthlessly purge the unnecessary (or store things for reference)

Allen actually provides a great checklist for performing the review available as a free download.

Using a Trigger List

You might find it tough to start this process without a jumping off point. Allen actually created a pretty robust trigger list to help jog your memory. Essentially, this list is an overview of all the areas of work and life you might find yourself in. Just by reading through it, I am certain several items will jump out at you and trigger some thought you need to capture.

Keeping Going

Allen says you’re doing the review right when you can honestly identify everything you’re not doing. At its core, Getting Things Done is about feeling good about the decisions you make in doing some things instead of others.

Getting Things Done acknowledges that our work is never over and that there’s always going to be more to do than what’s possible in a given day. The review is in place to ensure you’re not forgetting something truly important, yet allowing yourself the ability to say “not yet” without guilt.

Useful User Stories

2014-02-21T08:15:30+00:00

## Why Write User Stories? Developers can take notes and problem solve. The typical user story syntax is clunky and meaningless. I can get my point across without them. These are all true statements, but they're also full of misconceptions. Too often, requirements are given as a hallway conversation or email note by a busy executive who's trying to get something done. Two weeks later, the work is complete and it bears *zero* resemblance to what the executive had in mind. Therein lies the main problem: we're trying to collect information from each other's minds and without a shared perspective we often miss each other's point. User stories are the currency of our trade. They allow technical and non-technical folks alike to collaborate, plan and outline a product's requirements. With a well-defined and well-written story, teams can work together without ambiguity or confusion. ## Defining a User Story The basic definition of a user story is… > A description of functionality that will be valuable to a user of a system or software. To break that apart: 1. **Description.** This description should be well articulated, but not overly complex. Anyone should be able to read it and explain it back to you. 2. **Functionality.** It must be specific enough that it *does* something. This is not marketing copy. 3. **Valuable.** The most important part. Why should we be building this thing, anyway? Does it save us time? Make us money? Is it just mind-bendingly awesome? 4. **User.** Who are we doing this for? Bob in Accounting? The executive team? Our core user group? A small, but valuable, subset of our users? 5. **System or software.** The domain in which we're working. Where does the story fit in the overall arc of our product? ### User Story Syntax The basic components of a user story are… >As a << user >>, I want << feature >> so that I can << receive value >>. Three modular pieces: Users, features, and value. As mentioned before, the value is the most important part (and I often write that part first). Why should we care about this story? What is its happy ending? What does the thing actually need to do, and who does it serve? There's more to it than that, but that's the basic operating syntax. Modern stories often turn into full-on *narratives*, which contain Later, we'll talk about how to actually write them and how to collect requirements for good stories. ## Writing Good User Stories First and foremost, a good user story allows us to easily have **empathy** for our customer or user. Sure, it's a buzz word, but an important one: knowing why our users can benefit helps us create better software to serve their needs. When we downplay the importance of understanding our users, we end up with terrible interfaces and cludgy experiences that satisfy requirements, but don't delight. ### Start with the User They're called user stories for a reason. We need to have a solid understanding of the user's interaction with our software in order to write for them. I'm not talking about personas or demographic identification right now (although that is important). I'm more concerned now with *who* is actually using the system and what their technological abilities and constraints are. In brainstorming the user role, simply name the individual type who will represent the role. Organize the set by sorting the roles into relationships between them - overlapping and adjacent roles. Things to think about: * The user's level of domain knowledge The user's technical proficiency The user's proficiency with the software The frequency a user will interact with it The user's goal for using the software The user's context for using the software (mobile!) From there you should have a solid list of key user roles and how they're going to interface with your product. It should become somewhat clear from this alone what key requirements are for each group. ### Story Rules A good story must also follow agreed upon guidelines. This is really well articulated in Mike Cohn's reference, [User Stories Applied](http://www.mountaingoatsoftware.com/books/user-stories-applied). He co-opted the "INVEST" model for writing stories, which is: * "I" ndependent (of all others) "N" egotiable (not a specific contract for features) "V" aluable (or vertical) "E" stimable (to a good approximation) "S" mall (so as to fit within an iteration) "T" estable (in principle, even if there isn't a test for it yet) Another key tenet of user stories is laid out here: stories aren't a commitment, but a *reminder*. They're a placeholder for a more detailed conversation and an overview of an idea. One shouldn't expect that a user story alone gives a team enough information to go off and build something. As we break a story down into its component parts, we start outlining its needs. A few things that come alongside a user story in later planning: * Wireframes or UI design * User workflows, content and form fields * Acceptance criteria * A development checklist and estimate The closer you are to a story in your planning process, the more detailed it needs to be. Conversely, the farther a story is from an iteration, the larger and less precise it can be. These less precise stories are often called **epics**, as they end up containing large swaths of functionality and multiple stories themselves. They're not bad stories, just big, and will ultimately get broken down into their component parts. #Collecting Stories I write stories almost exclusively on 3"x5" notecards. I **love** notecards. They're cheap, physical objects that can be moved around, grouped together, or (my favorite) torn up. I also typically use a standard Sharpie marker, as the physical constraint forbids me from writing too much detail on a card. Sometimes I lay them out on a table, on the floor, or tape them to a wall. They typically get grouped, organized, prioritized and discussed in great detail while they're still physical cards. ![Organized User Story Notecards](http://cl.comenerdwith.me/V6wS/stories%20on%20a%20wall.png) There are a few ways we can retrieve user stories from a disparate team of people or groups of users. To help get people thinking and articulating their thoughts further, I often like to facilitate a workflow workshop. Start with an empty box and use this as your starting screen or interaction point. Walk through what happens next, and take a depth-first approach: follow each trail to its end rather than trying to go one level deep across the whole experience. While doing yourself, prompt the group with: * What will the user want to do next? * What mistakes might the user make? * What additional information might the user need now? Focus on quantity over quality at this stage. You're brainstorming, so postpone UI. Sometimes I'll even draw circles or just words on a whiteboard to remind everyone that we're not talking about how something *looks*, but how it *works*. Boxes look like buttons or screens, so defer that visual thinking until the idea's been articulated. Now we have a list of key users and an understanding of what they need to do with the product. It's time to actually write stories. I like to facilitate short bursts of creative writing, normally around Card Passing. I use a [Time Timer](http://www.timetimer.com/), a really fantastic visual timer, to keep things moving. I typically go through a few different ways of writing stories, all with stacks of notecards around a table with our stakeholders and clients. ![Time Timer](http://cl.comenerdwith.me/V5n1/time%20timer.png) #### Individual Writing Normally I'll set a five minute clock and have everyone "claim" a user workflow or feature set. Then each person writes as many cards as they can. Once the five minutes are up, I read each card (without revealing its author) and allow the group to sort the cards and identify duplicates. **Remember, we're still brainstorming.** I don't tear up any cards… yet. #### Group Writing Next, I'll set the timer and have each person at a table write the “As a…” statement then pass the card to their left. The next person writes the “I want…” and so on. Complete cards in this way until your time has elapsed. Then, start with the “So that…” and then the “As a…” - "I want…"" comes last. Passing cards forces everyone at the table to stop thinking linearly. They're often presented with a user type or business value they don't normally think about, and so they have to creatively come up with ways to serve those needs. I find that group writing typically yields more in terms of card volume, and, as you'd expect, the general quality of the cards goes down. That's ok – the point here is still quantity over quantity. Once we're done, I stop the group and we check in again by reading all the cards. It's important here to make sure all users are represented and at least *some* level of functionality is recorded for each of the workflows, features and ideas we've had around the table. Once we've confirmed that as a group, we start sorting. ![User Story Sorting](http://cl.comenerdwith.me/V6xk/organizing%20user%20stories.png) Story sorting allows us to weed out bad ideas, poorly written or duplicate cards. It also allows us to stack relevant thoughts together as we chain features and needs together in a workflow. Ultimately, we strive for consensus but it's always best to have a true product owner in the room to establish priority and our team's direction. Now we have an idea of what we're building. Feel good? This process should be draining, but incredibly satisfying. We're just getting started. Next time, we'll unpack how to add the right amount of criteria to our stories so they can actually be worked on. ### Acceptance Testing Stories User stories are great placeholders for functionality, but they're not all the functional requirements we need. To go deeper on actually conveying need, we integrate a series of acceptance tests to confirm a story is satisfied. Or, put another way: how do we know when it's done? A few ground rules: 1. It’s better to write a short story and a longer list of metrics to test. 2. These tests should be written before coding. 3. These tests should (typically) not be written by the actual developers. 4. These tests should comprise the QA script for the team after coding. #### Writing Acceptance Tests Acceptance tests are detailed list of requirements that accompany a story. They should be actionable and task oriented, centered around the following thoughts: * What does the team need to know about the story? * What can go wrong during the story? * What am I assuming about how the story will be implemented? It's a good idea to use a consistent tone and syntax here, too. Our team follows the “Verify That…” approach. The first line of your acceptance tests should begin with that phrase, and what follows can be a simple list of to-do's, essentially. This allows the developer as well as te QA team to ensure the requirement is met. #### Behavior Modeling Another way of explaining detailed functionality is via a behavior model. This layout gives another consistently phrased approach to how we handle individual requirements. The syntax is: >Given that I am << on a page >> and I have << performed an action >>, I should << see this reaction >>. This model is also great for QA and bug submissions. Simply add, "Instead, I expect << desired functionality >>." to the end of that line and you've got a really well detailed error report that can be submitted to a developer. I often write these tests on the back of the user story notecard. Again, this limits the amount of detail I can add to a particular card (and instead implies that I should break complex stories down into multiple cards or enttities). So now we've got a big pile of well written, thought out user stories and they even have acceptance criteria. Next up: how do we know where to start? ### Prioritizing Stories Over this series in user stories, we've gone through how to identify users, how to lay out their needs, how to document them into stories, and how to put additional detail around those requirements. Now we need to answer the tough question: what do we do first? Typically, we always seek the easiest, highest value items to work on next. To get there, though, we still need to determine what's easy and what's valuable. #### Valuing Stories For every story, we think through the following: * How desirable is this story to the core user group? * How does this story impact overall cost? * How important is this story in relation to other stories? Each story then gets assigned a relative value to identify how important it is compared to others. We like the MOSCOW method for identifying business value and priority. It's easy enough: >**M**ust have, **S**hould have, **C**ould have, **W**ant to have Every story card we write ends up with a relative value assigned to it by our product owner. Or, we might go more in depth using a system like the [Kano model](http://en.wikipedia.org/wiki/Kano_model). I love this model for its dispassionate ability to organize ideas into areas of value. It's easy enough Another great exercise is **story shopping**. We can assign a baseline value to each story (possibly from our initial estimates) and allow our stakeholders to "shop" for them with a fictitious amount of money. Of course, we ensure there's more points on the table than the client has in terms of fake money – so, preference and choice emerges to help complete the exercise. It's subtle, but using scarcity quickly shows us what we need to be focusing on and what items can wait for later. #### Estimating Stories While a product owner is evaluating the relative business value of our stories, a development team should be reviewing them to discuss the potential time (and thus, cost) each story will take. This figure can be incredibly important when making the decision of business value: a story that will take two weeks might be less desirable than one that takes two days. The only way to know is to confirm with our development team. Like writing the actual stories, our team needs a common language in order to establish the recommended cost of each story. That language should allow us to: * Change our mind when we have new information about a story * Plan for epics and smaller stories * Not spend much time estimating * Provide useful information about our work and the time remaining * Take imprecision of estimation into account * Quickly plan releases To that end, it's best to use abstracted points rather than estimating in hours. Points represent no real unit of time, but are a currency an entire team can comprehend. A scale of points is simply a measure of _relative complexity_. A 20 point story is four times larger than a 5 point story, and so on. It's a good idea to use pre-defined values like the modified Fibonacci sequence: 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 80. A logarithmic scale like that reminds us that point precision decreases as story sizes increase. To keep things simple, we sometimes use a difficulty scale, where 4 points represents an extremely complex story, whereas 2 points is half as difficult. Again, remember that an estimate is really a "size", not a true time estimate. t's always best to think of how stories relate to one another in terms of relative difficult and assign that point value accordingly. #### Estimating Meetings Here's an effective workflow for how to convey user stories to a development team, clarify their needs and then produce an estimate. 1. Gather the team (Customer team and developer team) and share the stories. 2. The customer or customer team reads a story to the developers. This should take a while. 3. The developers ask questions, the customer clarifies (take good testing notes!). 4. Each developer should write a story point estimate down for each story without showing the other developers. 5. At the end of this process, each developer should share the story estimates with each other. **They will differ.** 6. The high and low estimators will need to explain their decisions and discuss for clarity with the group. 7. From there, the group should converge on one point number estimate for each story. The points estimation process here is often called "Planning Poker", since it involves a sort of card game like estimate reveal. Allow developers to discuss points, rather than just arbitrarily handing them out. Allow developers with experience in one area to claim a series of stories so they might assign a lower point value to them. Allow junior developers to place a higher point value on an item and claim it for themselves (or better, to pair up with someone else on it). Organize the story cards into a digital system like [Trello](http://trello.com) and allow the business stakeholders and product manager(s) to prioritize the stories at will. The development team should make recommendations on how to address the right order of a stories, but ultimately the business is responsible for choosing what work happens first. _Expect the order to change frequently._ ![Agile Trello Board](http://mrdanadams.com/images/trello/board.png) Once we're into a system like this, we've now got a prioritized, estimated and well-organized backlog of work that our team can start chipping away at. The goal here, again, is not to keep things set in stone; the team gathered and learned enough simply _to get going_. This backlog should breathe. It should rise and fall as stories are added and completed, and should change structure frequently. The list of stories can always be polished, pruned and expounded upon (and we should welcome it). Review the backlog frequently to remove dead weight and add new insight. It's a constant dialogue; the stories are just the cue cards.

Jonathon Arnold

This Is Product Management: Collaborating with Agencies

Three Quotes About Creation

On Problem Definition

On Customer Needs

On Understanding Users

Product Management Pitfalls

Timing the Roadmap

Commitments

Crunch Time

Decision Making

Strong Opinions, But…

Decentralize Decision Making

Comfortable with Uncertainty

Going Forward

Recommended Reading

The Dungeon Manager

Product Management as World Building

Macro Arc, Micro Arcs

Product Vision

Open World

User Appropriation

Here Be Dragons

Iterative Design

Leveling Up

User Onboarding

Non-Playable Characters

Humanizing the Product

Steal from Everywhere

No Really: Steal from Everywhere

And Most Importantly…

RailsConf 2016: Managing Growing Pains

Natural and Reactive Planning

Learn to plan from your brain.

Natural Planning

Brainstorming

Reactive Planning

How can you change the conversation and move away from planning out of worried necessity to planning on instinct?

Testing Your Way to a Better Idea

The Minimally Viable Product

A Non-Profit Discovery Process

Finding the Problems

Here’s the Non-Profit Canvas.

Finding the Solution

The common issues are:

Every non-profit needs to…

Some Deliverables…

Curate.

Connect.

Cultivate.

Convert.

The Weekly Review

The Weekly Review

…or checking on your checklists

Performing a Review

GATHER

REVIEW

IDENTIFY

Using a Trigger List

Keeping Going

Useful User Stories