Our data, ourselves

As a Product Manager specializing in data and analytics, I often grapple with problems of access to data, whether it is data about FDA-approved medications, healthcare costs, or how to speak as a citizen in what is supposed to be a democracy.

What are the problems?

There is incredible ambiguity around the question of who owns user data that we as a society consider to be private. For example, a relationship breaking up is a data point that you may not want sold to other companies. That’s why it’s a problem that people don’t believe Facebook when they claim in their Terms of Service that users own their own data.

On the other hand, a ton of data that we would consider public is locked away in proprietary systems and is not freely accessible to people and projects. For example, where can I go to tell my city councilwoman what I want from a proposed legislative action about, say, allocating tax revenues from sugar-sweetened beverages? Talking to local government should be easy, but in many cities and municipalities, data about where our local government meets and how to speak to them is hard to access, hidden somewhere in a rabbit-hole of links that lead you to PDFs that lead you to other links that lead you to something resembling a schedule of meetings.

What are the solutions?

We need our private data to not be sold to companies without our knowledge and consent! This can mean a whole host of defensive solutions we can implement as individuals as a stopgap while we hustle as a democratic society to pass and enforce legislation that protects us from our data (and our selves) from being sold for profit without our consent.

We also need access to public data that we actually have a right to access! Solutions like everypublicmeeting.com makes data about public meetings more accessible and open, so that we as a civil society can actually show up when it counts. In addition to open data projects like this, we need to create standards around how to open up public data, like what is laid out in the Open Data Handbook published by Open Knowledge International.

Why does it matter?

As human beings, we move about the world saying and doing things that impact our environments, ourselves, and other people. Our humanity is in large part defined by all this activity, which consists of characteristics like “I went to SoCal for two weeks on vacation” and “We are going down to City Hall on Monday to speak about a proposed legislative action” — which can and is often encoded digitally as data.

If what we do is who we are, then:

  • We need to be able to keep private parts of ourselves protected as we choose.
  • We also need to be able to access public parts of our society so that we have a say in the rules that govern the public parts of our lives.


Cracking the PM Interview

Lately, I’ve had a number of people reach out to ask for recommendations on skilling up as a product manager.

Cracking the PM Interview

There are a zillion things to read on this topic, but I usually offer a single resource — the book, Cracking the PM Interview by Gayle Laakmann McDowell and Jackie Bavaro.

If you don’t enjoy reading this book, you won’t enjoy being a PM.

Why? Because this book shows you all the stuff you’ll need to know to succeed at an interview, which is your first step towards succeeding at the job where you have to actually do all the stuff you talked about during the interview 😉

Product interviews are hard because product jobs are hard.

As a product manager:

  • You have your hands in ten different projects all day long,
  • So, you switch contexts as often as you breathe.
  • Managing people’s feelings is a huge part of the job…
  • …and doing a bunch of really technical stuff is too! 😛

This book is a microcosm of what you need to know to succeed in an interview for a product manager job, and the interview in turn is a microcosm of what you need to know to succeed in the job itself.

Product roles are some of the widest and deepest roles around (which is why they can. You might embrace your brand as a generalist, or decide to specialize in technical/design-focused/marketing-focused/analytical product management. In either case, this book covers a lot of ground, teaching you how to estimate things, choose between feature sets, write algorithms, make a product roadmap, and practice leadership skills.

Go read it!

How does a Product Manager fit into a business?

A Product Manager’s job is to help the business make more money than it spends.

The Product Manager (PM) does this by developing new products that provide value for the business’s customers, which in turn generates revenue for the business.

The PM develops new and valuable products for customers by performing two kinds of tasks:

  1. Identifying which products and services provide value for customers
  2. Building the products and services that provide enough value to customers that they will part with their money to buy your stuff.

In the software startup context, what these two kinds of tasks entail will differ based on the stage of the company where you work as a PM.

birth -> growth -> actualize

#1 Birth

Your startup is born! Aww!

Similar to caring for an actual newborn (so I’m told), these are hard days full of sleepless nights and your top priority is to ensure that your startup survives.

Your main goal as a PM here is to achieve Product Market Fit. You will do this by shipping MVPs, learning, and iterating.

How do you know you’ve achieved Product Market Fit?

If you are struggling to achieve Product Market Fit, the problem is in either the identification of the right value to your customers, the delivering of the right value to your customers, or some of both.

#2 Growth

You’ve made it through the birth and you have achieved Product Market Fit. Good job!!

It is now time to build a profitable business.

There are historical precedents for how businesses grow, and it is possible for some businesses to grow astronomically and break these precedents, but it is more plausible for some businesses to set realistic (i.e. closer to normal) targets for growth.

“Growth” here can mean an increase in users, an increase in revenue, or both.

As the PM, you will want to track metrics to help you identify whether or not you are delivering the right value to your customers, and to help you build more things that deliver value.

The point of tracking metrics is to eventually suss out how your company will make more money than it spends.

Making money

Metrics here include:

Revenue adds up to things like:

  • Gross Revenue
  • Gross Margins
  • Contributing Margins
  • Operating Margins

Spending money

  • At the customer level, you will want to attend to the CAC (Cost to Acquire Customer)

Opinions abound as to what the values of these metrics should be during the lifecycle of your startup:


Dave McClure’s “Pirate Metrics: AARRR!” is a comprehensive framework for growth metrics for startups.

This breaks down to some of these easy-to-remember acronyms:

    • Acquisition
      • DAU / WAU / MAU
      • CAC
    • Activation
      • Activation rate
    • Retention
      • CCR: Customer Churn Rate i.e. Attrition Rate (i.e. how much are you hemorrhaging customers)
      • MRR: Monthly Recurring Revenue — a function of retained users that don’t hate or may even like your product 😉
    • Revenue
      • ARPU (Average Revenue Per User)
      • LTV (Lifetime Value)
      • RPP (Repeat Purchase Probability)

As you track metrics, build features that favorably influence your metrics. You can:

  • A/B test variations of your product to increase conversions
  • Run Design Sprints to launch new verticals
    • Remember that the needs of the buyer can be different from the needs of the end user, especially in the enterprise context

#3 Actualize

If you’ve gotten to this stage, congratulations! You have grown into a profitable business, which is no small achievement.

At this stage, your priorities as a PM have drastically changed. You will now be thinking about how to:

  • Optimize (reduce operational inefficiencies).
  • Scale sustainably.
  • Hire the nicest people who are also highly-skilled.
  • Be a market leader
    • Keep up with the competition: Disrupt! Innovate! Constant Vigilance!
    • Create the workstreams and systems you need to make ambitious things in the world.
  • Build an ethical company: This is not just a PM’s job, this is everyone’s job, which means it’s also the PM’s job.
    • Create a good culture — be good to your people.
    • Engage with the community.
    • Ramp up your Diversity & Inclusion initiatives.
    • Make the world better.

Product management isn’t complicated but it’s hard

I’ve been a product manager at health tech startups for a few years now. Recently, I’ve been seeking books and articles about becoming a “good” product manager, especially in a startup setting. And I’ve come to the realization that this is not some magical secret held by the guardians of product management. 

Managing product is simple, in that there a bunch of steps and you have to actually do all of them.

Doing the work, doing all the work, is hard. You have to invest focus and time into your work, and you have to care a lot about your output in the form of a product.

The products that you are building have to be things that you closely identify with your self-worth, in the organization and maybe even in the world.

If you don’t feel that strongly about it, you’re probably not going to do a great job managing product.

Assuming you care enough and want to do a great job, let’s outline what the work actually is.

The work of managing product consists of:

  1. Understanding the things that everyone is asking for

  2. Understanding where they’re coming from when they’re asking for all these things

  3. Getting people to start making some of these things

  4. Helping people finish making the above “some of these things”

  5. Launching the things

  6. Helping people use the things

Let’s dive further into each of these aspects of the hard work of product management.


#1 Understanding the things that everyone is asking for

You will need to understand deeply why everyone is asking for those things. This means:

  1. You know what all the aspects of the things are. This basically means you understand the feature, and you know how they are picturing it in their heads as fitting into some existing product that your organization already uses or sells.
  2. Why the people asking for them care so much about the thing. Curiosity and empathy are helpful here. Try to get in their head. What is causing them so much pain that they have to ask for this, or what is exciting them so much about the prospect of asking for this thing?


#2 Understanding where they’re coming from when they’re asking for all these things

You’re going to do this based on the goals of your organization. If you don’t know what the goals are, or realistically, the one thing you need to achieve this quarter, you’re going to be lost.

You need to figure out who it is that decides what the goals are, and you need to make sure you know how this is expected to be measured and that you agree that these should be the goals and the measurements.

If you don’t agree, speak up! Chase it down! Figure it out! And write it up for everyone to see.


#3 Getting people to start making some of these things

You will talk to talented designers and engineers about the right subset of the above giant pile of things, and you will ask them to help you make it real.

You have to be humble here because you’re not their boss. Whoever is running design and engineering are their boss.

Here is where you have to convince them that these are the right things to build at this time. You can use stories about how not doing this will create pain for your users, or stories about how doing this will create delight and value for your users. You can use metrics about reducing implementation time, or increasing sign-ups, or what have you.

Just have your act together.

Having your act together is really important at this time, and at all other times, lol. This is the secret of good product managers (and of good anythings), it’s that they have their act together.

This means they know what they’re doing, why they’re doing it, and they are organized in how they tell people.

If you don’t do the work ahead of time of thinking through what you will present to these makers, these doers, these engines of your organization, you will not be informed or persuasive. Therefore, you will not look informed or persuasive. You will sputter in front of all these people if someone has a question or a challenge. So have your arguments together, your documentation in order, and your presentation polished and fully prepared before you ask your talented peers to help you create something new in this world.

Don’t let this conversation drag on forever. Have your one or two meetings, and ensure that everyone that needs to be in the room or dialed-in is present. It will take you forever to get stragglers on the same page if they’re not with the group right now.

During your meeting when you are asking people for things, don’t get frazzled if people have questions, or it takes you time to explain to them why it is that you’re asking this of them. Be confident and be a fount of knowledge.

Not knowing why you are asking them for these things is a cardinal sin in product management. Never be in a position where you don’t know why you are asking your team for things.

They may not say it, but they will hate you for asking them to spend their life energy on something that you don’t even understand.

Be a good speaker when presenting and answering questions, and speak at a volume at which everyone can hear you. And if someone has objections that sound real, take that into account, and adjust your list of things you are asking them for accordingly. Document the changes and confirm them with your team. Be decisive and talk in such a way that people know that this is now the new plan on which everyone has to execute. Don’t accept excuses like “I thought we were going with X but now we’re talking about Y”. We are not just talking about Y now, we are now going to be doing Y. Decide, and tell everyone that that’s what we’re doing.

Assuming you get through this conversation and address all concerns and get everyone on the same page with the finalized list of what’s going to get built, you are now going to help your peers make these things real. They are going to start working on these new features, tasks, or bug fixes. Some of this work has to happen in sequence:

  • Design might have to talk to the customer to quickly validate a requirement, or create an interface for engineers to build. Help them make that happen by scheduling the meeting with the customer if you have to. Make sure the conference line is functional and works well. Remember, this is about doing a great job at managing product, so don’t skimp on really important details like a functioning conference line. Test it ahead of time if you have to.
  • You will have to write requirements for QA to write tests cases off of. Do a good job with this. Know the corner cases you’ll have to address, and explicitly speak to them in your documentation. Write documents that QA can access. How QA is able to access documentation should never, ever be a mystery to them. Be on hand if they have questions about how to write one of the test cases. Be responsive and respectful of their time.
  • Engineers will have to create product for QA to validate. Be around to help them out with their questions. If they decide to simplify the implementation for some reason, be there to weigh in on this if you’re needed, and definitely know that this is happening. And of course, document any changes. 

There is also some leftover work here, that you absolutely have to do, which is communicating with the people who asked you for the things.

  • You have to let the ones who are getting stuff know that they’ll be getting stuff.
  • You have to let the ones who are not getting stuff know why they are not going to get their stuff this time.
    • If they will get it later, tell them that.
    • If they will never get it, tell them that.
    • If you don’t know, tell them that.

You need to help all of these “askers of things” trust you. Don’t be a flake, and don’t let things fall through cracks. It is too easy to ignore the things that don’t get made and the people who asked for them. It is hard to document things in such a way that you have your requests observably sitting in a clear, comprehensive manner in some non-overwhelming location.

Do the work of figuring out how to document what is happening and why, and what is not happening and why not.


#4 Helping people finish making the above “some of these things”

Finishing the work of making the things you decided had to be made right now is an extension of Step #3 above. This will require back-and-forth from each of your teams that are building things.

It is your job to help them finish the process of making it real.

When you help them make it real, this is you actually helping them help you make it real.

Your job is that this thing ships. It is critical to get this work completed, and minimize the starts and stops to the fullest possible extent.

I will remind you that again, people lose motivation when you don’t have your act together. So, have your act together. Get your tickets ready in your ticketing system, each with sufficient information, and get your PDFs of the interface uploaded into the tickets, and get your documentation in order so that QA can do their work on time so that you, yes you, can ship bug-free software.


#5 Launching the thing

Launching a product is about focus, stamina, and teamwork, not magical knowledge that someone else has that you don’t have. It is the sum of all the parts thus far, and the tying of the bow around it.

Launching your product will mean writing release documentation and telling people that it’s going to happen. If you set a date, make sure you tell people whether you’re planning to launch on that date. Don’t wait for three different people to come to you to ask whether it’s still on schedule. You should be pushing out these notifications, not waiting around for someone else to tell you whether it’s going to happen.

If you’re launching something of a big enough magnitude, i.e. a new product or a big new feature, you might work with customer-facing folks and with marketing and with sales, to make sure that your customers and your market know about this new, real, useful, valuable thing you are releasing into the world.

All other launches will probably also involve some kind of communication out to the customer, whether that is an internal user or an external user. Make sure you do this work of letting them know that their thing is now ready. Make sure they know what benefits they will enjoy if they use the thing.

  • Will it now save them 30 minutes to do some menial task?
  • Will it enable them to do their work more safely?
  • Will they now be able to service 20% more people in the same amount of time?

Figure out the benefits and lay them out clearly for your customers.

As you launch, you also need to do the important work of celebrating, and of acknowledging everyone who created this product or new feature or critical bug fix. This was a team effort. It is always a team effort.

There are always people who have given their life energies to making this happen, to creating this thing that you asked them to make.

Give them their due, and know that you have been successful in your launch because of them.


#6 Helping people use the thing

Now that the thing is out, you need to ask your users how they are using them, and if they need any help. Sometimes, all it takes is a little bit of training. Again, have your training materials ready. If you think they’ll read documentation, write documentation ahead of the launch and ready to share it with them. If you think they’ll watch training videos, budget for time and people to help you produce these while you plan your post-launch activities.

Sometimes, sharing this training material will actually be part of the launch. Sometimes, much ado may not be necessary. Make the necessary judgment calls when deciding how deeply you want to get into training, and err on the side of over-communicating how it is that they will be using this thing.

Check in on them after a day or two, and see if they’re using the thing. You might want to sit with a user and watch them use the thing, or use the thing with them. It is your job to make them comfortable with the thing you’ve made.

But if the thing is bad, they will never be able to be comfortable with it. When this happens, it is your job to 1) know how you are going to fix the thing, and 2) tell them how you are going to fix the thing.

You will have to bring their feedback back to your team, and you will have to do this in such a way that you are not blaming anyone or making anyone feel bad.

This part is hard. You have to clearly state what went wrong, and then immediately, you have to refocus on building a better future for your users, with the help of your talented peers who are the ones with the actual power to create new things in the world. Make sure you have your requirements right this time! You can only fail so much. 

In B2B businesses, you actually have the luxury of failing less, if you really listen to your customers and properly document what it is that they have asked you to do. This doesn’t mean you give them everything they asked for. It means that you use their requests as a way to know their problems, and you institutionalize this knowledge in good documentation. You disseminate your knowledge using good communication systems.

Clearly, all this is work measured in hours, days, weeks, and months.

You have to build systems that help you put in the hours of actually doing the work, systems that make doing all this work with all these people a little easier.

I’ll get into the systems that help you do the work in later posts.