About · Posts · Categories · Projects · Mailing List

As a Product Manager I don't have a typical day. The only consistent element is change. And being at a software company change occurs quickly and often. Add to that a startup environment, and you get a fast-paced setting with shifting priorities and never-ending to do lists.

This quote by Reid Hoffman sums the feeling:

Starting a company is like throwing yourself off the cliff and assembling an airplane on the way down.

Here is an example of a recent workday. At the start I answered questions from our offshore development team related to feature requirements. I then did user acceptance testing (UAT) for a new Chromebook version of our app. This was followed by leading an hour-long brainstorming session with the product team where we established requirements for an in-depth data analysis project our product intern is doing. Right after I presented our operations team a new feature in their internal user management tool (I had spent the previous evening writing  an exhaustive list of test cases for the operations team to go through to test this new feature). This was followed by reviewing a list of open Android and Chromebook bugs (the builds are currently in beta) and adding user stories to our backlog. And there ended the first half of my day.

In order to be productive I strive to block distractions. I refrain from keeping my inbox visible while working. Email can quickly derail momentum so I keep it out-of-sight. I do the same with my phone so I'm not distracted by incoming notifications. I'll also keep headphones on and loop through albums I've listened to hundreds of times. Music helps me focus on the task at hand and provides a little extra motivation when a task gets difficult. These distractions I can control. But there are plenty that I cannot.

An in-person question from a colleague. A ping (Skype, Slack, Hangouts). The email with subject line "urgent". These impromptu "interruptions" or "distractions" are not bad, they are a natural byproduct of work life. They are part of the appeal of working in an office versus working at home in solitude. But they can be dangerous if they control you instead of you controlling them.

In my role an interruption is typically product related. How does X feature work. We should look into Y. Let's make sure development works on Z. They are all valid for the moment, but in most cases (production issue being the exception) don't need immediate attention. They can be deferred. And so I've developed a process for keeping track of these things while maintaining focus on current priorities. I'm the last line of support in order to see a task through. If it falls off my radar, it may not resurface again until a user brings it up.

My process is built around this principle: set it and forget it.

Whatever the item is, I want to  quickly capture it, and store it in a place where it will resurface the moment it should be addressed. For example, a question that needs developer input is asked. Instead of interrupting the developers (or my) flow, I open a shared meeting notes page (using Confluence) and record the item. Our development team is remote, and so we have  morning sync calls three times a week. Each call has an agenda of topics ranging from current projects to user stories that need grooming. And so during this call the deferred question resurfaces and is addressed. The meeting is set to happen anyway, so it makes sense to address the question then instead of the moment it first came up.

For this system to work you need to have the right tools and a certain culture. My toolset includes Confluence, Trello, Evernote, and Google docs. My team uses Confluence to capture meeting notes, product specifications, and general product documentation. I'll use Trello as my personal "to do" list for items that I differ and am responsible for. I'll use Evernote to capture personal notes when they don't need to be available to everyone on the team (otherwise I use Confluence). And Google docs (especially sheets) is a great all purpose tool that is used in harmony with Confluence. The beauty of each tool is I can quickly capture a deferred item, and because of the system, I know it will resurface at the right moment. I have browser bar shortcuts to Confluence pages and Trello boards. Once I have something to capture I pull up the page, capture the item, and continue with the task at hand.

Set it and forget it.

Once you have your toolset, you need to set your mindset to deferring things. This is a cultural shift that may not be openly received by your team. Especially if they are used to having immediate satisfaction. As each team and situation is different, there is no magic formula. You'll just need to start and manage expectations.

Constantly think about what do we build now versus later? Or more generally, what do we address now versus later?

Product discussions can be ambiguous - especially when discussing a bug or new feature. The discussion can quickly deviate to edge cases that become the conversations focus. Instead of striving to find the best solution for the known problem, "what ifs" dominate the discussion.

What if the user does this, how will our solution hold?

These questions put the group into an unproductive and awkward state. Feelings get hurt and morale destroyed as the group debates inconclusive questions. It's like debating whether green is a better color than blue. Valid arguments can be made for both, how do you pick one? Then someone adds purple to the mix and the group falls deeper into the endless debate spiral.

The group should have one person with a comprehensive understanding of the issue (bug, feature) being discussed. This person is the mediator.

The mediator in product issue discussions must know how the product works. Not at a code level, but at a practical level. The mediator can confidently answer how the product behaves when a user does X or Y action. The goal is to get the group to a decision. The mediator should not abuse their power by pushing their agenda. Instate a culture where the best idea wins. Guide the group to find that idea.

Knowing how the product works provides the mediator with the antidote for edge cases: the work around. Edge cases can destroy momentum as a variety of resources (developers, operations, QAs, etc.) are pulled in to create a solution for a problem that a small percentage of users might experience. The work around saves time and frees up resources to work on higher value tasks. It also provides  a solution if the edge case happens. But to know the work around, the mediator must know how the product works.

The responsibility of knowing how the product works falls on the Product Manager. Knowing what happens if I push button X when setting Y is on and how that impacts feature Z. Getting that knowledge requires dedicating time to coming up with test cases, running them, and documenting findings. Such tasks (that do not have a clear owner but are necessary to move the product forward) must be taken by the Product Manager. It's the non-glamorous aspect of a Product Manager's job.

The task of testing your product under specific conditions can be tedious and time consuming. But time must be made for them. Running the test yourself is the only way to truly know how your product works. Tasking a developer with looking at the code is not enough. You are not only pulling them away from other tasks, but they may overlook a particular code block that gets invoked in a particular case you did not explicitly state.

As a Product Manager, three elements comprise your responsibility of knowing how the product works: curiosity, effort, and time. Be curious, come up with questions on what happens if I do X, Y, or Z. Put in the effort to run tests yourself. Try to "break" the product. Find the delicate balance between delegating tasks and doing the things no one else will do. And although you can't make more time, you should allocate time so that you learn how the product works.

If you don't do it, who else will?

Startup companies are susceptible to building products that don't solve real problems. Instead of solving a real problem, they solve a fictitious one. The team fabricates a target user based on their idea - even though such a user may not actually exist. Herein lies the problem: since the idea came before the problem, the problem is a byproduct of the idea.

So the problem being solved may not actually be a problem for anyone.

Mark Hurst in his book "Customers Included" argues the importance of talking to customers in order to inform product decisions. He states:

Customers want a simple, unadorned solution to their problem.

It's an oversimplified but accurate depiction of an entrepreneurs purpose. To create a solution that solves a customers problem. To get there you need to start with the customer. Instead of dreaming what if scenarios you start with a tangible problem.

Dreaming what if scenarios can be fun and inspiring, but it puts you at risk of dreaming an idea that doesn't have a tangible problem.

I recently had an idea for a tool that would store the principals that you live your life by. It's LinkedIn meets About.me meets Twitter. A digital locker of motivational quotes. But what problem is this idea solving? I formulated a persona of a tech-savvy twenty year-old who meditates and does Yoga. Even though such people exist, do they have the problem of not having a tool to store their motivational quotes? Do they need such a tool? Is this a burning problem in their lives?

Even though the idea is interesting, the idea created the problem to justify the idea.

But the customer doesn't know what they want. So you'll build something visionary that will blow their minds and make them wonder how they lived without it. The probability of getting the idea right, followed by successful marketing/sales campaigns to get the product in the hands of your target users is very low.

Your idea may solve on one of three types of problems. A nonexistent problem. A problem the customer did not know they had. And a problem a customers knows they have.

The what if blank page brainstorming approach will likely get you an idea for a nonexistent problem. To get an idea that solves one of the other two types of problems requires a more focused approach. Whether it's talking to customers, doing research, reading (a lot), you need to focus not generating an idea, but on identifying a problem.

Once you know the problem you're solving, formulate your solution.

Don't do it the other way around.

Occasionally I come across a product that I don't understand after first use. I don't connect with it, and I don't see how it can benefit me. So I give up and uninstall it.

Sometime in the future the product enters my radar. A friend or person I respect describes a use case or feature that resonates with me. So I give the product a second chance. This manifests into a situation where I can't imagine a scenario where I'm not using the product. I become dependent on it. This happened with Evernote and Trello. And this week it happened with Inbox by Gmail.

Inbox by Gmail (or just Inbox) is Google's alternative email app to Gmail. Launched in October 2014, the app is designed to help you sift through email quickly, efficiently, and elegantly.  It bundles like emails, dynamically generates canned responses, produces Google now type cards with useful information, and has a game changing super-smart snooze feature.

Inbox can help make your Inbox zero goal a reality.

When you first use Inbox you may feel uncomfortable. It may be the same unsettling feeling you had when you switched from Microsoft Outlook to Gmail (where did the folders go?!). This is because Inbox is forcing you to look at email differently. The premise is to address the emails you can now, and postpone (aka snooze) all others. Your inbox is no longer a never-ending "to-do" list. Answer or postpone. Move on.

The types of emails we receive today are quite different from the ones we received 10 years ago. The latter was comprised of emails from friends, an occasional newsletter, and a random chain email. Today our inboxes are filled with endless notifications and confirmations, newsletters, deals, and all kinds of announcements. Inbox  was built for the modern email world. It's best feature is the speed at which you can process your email, but it has many other incredible features.

The snooze feature is my favorite. Left swiping an email brings up the generic Snooze window:


By snoozing an email you get to define when it will return to your Inbox. I dig the elusive "Someday" option. The "Pick place" is pretty powerful. Have a batch of work emails come in during your Sunday brunch? Snooze them to reappear when your at the office. Snooze is a brilliant feature and it gets even better.

Made a reservation at a restaurant and got a confirmation email? Snooze is smart enough to recognize this, and present you with an "Hour before reservation" option. Magic.


Got a shipping confirmation email? Snooze it to reappear on the Day of delivery:


Grouping is another great Inbox feature. I'm a big fan of Pocket. I receive their weekly "digest" email of top articles being shared on Pocket. Inbox creates a nice summary card by parsing the latest email from Pocket. I don't even need to open the email:


My favorite Grouping feature is under the Trip category. For my upcoming trip Inbox grouped all the trip emails together, and created an itinerary for me:


I can tap on each event in the itinerary and see details that include my reservation number, address, terminal, and gate. The convenience this provides is immeasurable. And I didn't have to do anything! Inbox does all the organizing.

I also dig the quick reply feature. I was on a thread with friends who are planning a weekend camping trip. Inbox presented me with some quick reply options if I weren't compelled to write a full response in the thread:


The quick replies are context aware, and adapt accordingly:


I've reached a point where I can't imagine using any other email application right now. Inbox is super convenient, fast, and fun to use! I highly recommend adding it to your arsenal!

As a Product Manager, one of my biggest challenges is kicking off development for a big project. Whether it's a new feature, process, or product, an endless list of unknowns and "what ifs" make starting the project daunting. It's easy to become intimidated and procrastinate the project.

Part of the challenge is not knowing where to start. Do I start by meeting with the development team? Or key stakeholders? Do I know which questions to ask so that the meeting is productive. What are the decisions that need to be made, questions that I need answered?

It feels like a writer staring at a blank page. Unsure which words to write first to start the piece. For writers that are unsure of where to begin, the advice I most often hear is to just start. Start putting words down and see where it goes. The action of starting is the trick.

For software development, I've come up with a system that helps me get started when faced with a challenging project. The system is based on a 5 column workflow table.

The columns are:

  1. Action
  2. Requirements
  3. Questions
  4. Discussion Notes
  5. To dos

Action is the specific action or event that takes place. It's a simplified list (an outline) of steps a user will follow (or events they will experience) when using the new feature. Each action should be short and easy-to-understand.

Here are three sequential items that would go into the action column:

  1. Select new Academic Year
  2. Classes and Students reset to 0
  3. Teacher accounts carried over without any class enrollments

This column is your starting point. The cumulative list of actions represents your ideal workflow. Write all actions you can think of prior to completing the other columns.

Requirements are the unofficial acceptance criteria for each action. Here you get into the details of what happens during each action.

Questions are the open questions relating to each action. Add your edge-cases and unknowns here. Add any items that require stakeholders to decide upon.

Discussion Notes is for tracking meeting notes. As you meet with stakeholders to discuss the new project/feature, take notes on what was discussed and decided regarding the action.

To dos are the list of things that need to be done.

Here is an example of an action event:




Discussion Notes

To dos

Classes and Students reset to 0# Class and Student lists for new academic year are blank
# Students do not appear in the new academic year until rosters are uploaded
# Should Student list be carried over from the previous year?
## Downsides to this approach?
# Ops prefers that returning students appear in the new student list# Andrei to meet with Operations to discuss additional requirements
# Dev team to investigate what process was during previous year

Once you've completed the first draft of your table, share it with relevant stakeholders and schedule a time to go through it. Cover each action and make note of the relevant discussion notes, questions, and to dos.

You likely wont finalize everything after one meeting, but you'll at least have a clearer direction of what the project needs to move forward.

Remember that the first version is a draft. Be flexible, move actions around. Your goal is to initiate a structured conversation about the project.