This year, we’ve decided to start publishing some of our insights. We hope that publishing these insights will attract top talent, and generate engaging conversations with leading businesses leaders who we can compare notes with.

Here are some of the recent content we’ve been publishing:

• How our automatic write-off detection tech works
• A new approach to live tax assistance, powered by LLMs
• Podcast: The story and vision of Keeper
• Podcast: Lessons on building with LLMs
• Podcast: Interview with Paul Koullick
• Ask an AI Accountant V2

Enjoy!

Below are some examples of the practices we’ve been incubating.

#1) We watch user recordings weekly

While building a lightweight user research practice is important, it’s not enough. Traditional user research calls are abstract, and time-inefficient. There’s often too much people-pleasing and ego involved to get to the truth. Between scheduling, no-shows, and prep, user research is also incredibly time-consuming. This often leads to a single person doing the calls and then summarizing the results to the rest of the group, which is even worse since 2nd-hand empathy is rarely powerful.

That’s why — at Keeper Tax — we’ve built a different kind of user empathy practice: every Friday at 4 pm we all sit down and watch recordings of people using our app. Prior to the meeting, each team member is assigned two users and asked to watch every single interaction they’ve had in the past week with our product. Then, as a group, we all show off our users’ journeys and share insights into their experiences.

Not only do these sessions uncover bugs, they generate discussion of actual user behavior, unadulterated by HIPPO or the narratives we all invariably tell ourselves as product-builders. Whatever new features we launched last week are typically the focus of the sessions, which is helpful since it allows every team-member to build empathy and product intuition.

It’s also a lot of fun! As the saying goes — the user is drunk. When (they think) nobody’s watching, people’s behavior quickly humbles even the most conscientious designs. There’s no substitute for watching someone rage-click an inactive button, or misunderstand the meaning of the new delete button we added.

#2) Every team member is a product analytics expert

At every company I’ve ever worked at, product analytics has been a walled garden, guarded by “analytics specialists”. This happens for two reasons: (1) the data tools & infrastructure are not set up for ease-of-use, and (2) the expectation that everyone should “self-serve” isn’t there.

At Keeper Tax, we treat product analytics differently. Every member of the team — engineers, data scientists, operations, customer support, and marketing — are all fully “product data literate”. Our tool of choice is Amplitude, and everyone uses it every day. It’s how we track our progress against goals, it’s how we make design arguments, and it’s how we keep each other honest as a team.

Note: to set up this culture requires an incredible amount of data infrastructure work. Without having the right foundation, it’s nearly impossible (believe me, I’ve tried). For starters, event naming conventions are key. But on top of that, it’s important to use a data pipelining service like Segment to ensure that there’s only one “source-of-truth” data stream powering other functions like lifecycle marketing, advertising, and more.

#3) We practice “humble design”

The problem with nearly every product design process I’ve witnessed is ego. It happens because a product designer’s job is incredibly difficult. There are near-infinite permutations, and open-ended “step-backs”, that could be applied to every decision they make. But someone needs to make the call. The natural human instinct is to adopt a frame of invincibility and design expertise … “I’m the designer, and I say this”. That attitude results in demotivated stakeholders (e.g. engineers), bad product decisions, and an unwillingness to revert them.

Instead, there’s “humble design”. It still requires deep thought and intuition, but also acknowledges that whatever you’re going to launch is probably going to need to get fixed. Every design comes with 2–3 “close calls” — tough design decisions that will be re-evaluated after the initial release. After a week passes and the team has looked at the data, the answers will be obvious.

Note: “Humble design” is NOT an excuse for shitty MVPs. Great design is always opinionated, and great designers must trust their intuition. There’s always a way to make something amazing with less resourcing, and there will always be room for a followup that doubles down on what works.

#4) We align marketing with product, as much as possible

Some companies are required to build two businesses: one that retains and monetizes the customer, and another that acquires them. This is often true for products like insurance (partnerships), or enterprise software (giant sales apparatus).

While there are many celebrated examples of where this has worked (e.g. DollarShaveClub, Airbnb), I believe that this splitting of attention results in a worse product experience long-term, and dangerous misaligned incentives. To build something amazing requires focus, and so at Keeper Tax we try (as much as possible), to re-use our product for marketing.

We try to evaluate every distribution channel not just by its effectiveness at acquiring customers, but also by how aligned it is to creating product and user value. Some channels — like content marketing and referrals — go hand-in-hand with improving your user experience. They should get extra points. Others — like partnerships and ads — can work really well, but create dangerous rifts in priorities.

The way we think about it, the best marketing is the most transparent and shows what the user experience will be. That’s why at Keeper Tax we invest a ton into our free resources — like our “Tax University” series and our tax calculators — which are the same resources we give our existing customers.

That’s also why our ads are just montages of user research clips. Here’s an example:

#5) We align revenue with user value

When people talk about having product-aligned revenue models, the most common culprits is enterprise sales. When the person buying something is not the one using it, that obviously creates issues.

But even within a consumer business, revenue models can easily slip into misalignment with product and user value. When we considered this at Keeper Tax, here’s how we mapped out our options:

At Keeper Tax, most of our revenue comes from a monthly subscription. However, as we’ve been adding new features and surface area (like tax filing), we’ve resisted the urge to include it in a higher-priced plan. That’s because we want to make sure that each new feature we add is valuable enough that customers are willing to pay extra to get it.

Another example is that we resist the urge to force our customers into an annual plan. While this can be great for reducing payback period, we don’t want to artificially create too many barriers for churn. It’s important that we know how many users consciously decide to stop paying us every month, in the same way that we don’t want to over-optimizing payment screens and cancellation flows.

Thanks for reading. If these practices resonate with you, consider joining us! You can check out open roles on our website.

5 Things We Do Differently at Keeper Tax was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been a product manager for five years. In that time, I launched features, product lines, and even entire apps from inception to scale… and I totally drank the whole CEO of the product and wearer of many hats Kool-Aid. So much, that three months ago I quit to start a company and become an actual CEO (of nothing!).

Very quickly, I learned that being a PM prepares you to be a startup founder in much the same way that running track prepares you for surviving in the wilderness. Not really. Here’s a list of reasons why.

#1 user acquisition

Holy moley… this one’s first for a reason.

As a PM, I was accustomed to worrying about retention, signup conversion, NPS, and so on. But not user acquisition. The users always came. Whether it was hitting the company email list, or simply adding a tab on the dashboard, there was always a straightforward way to get people into my product. “At worst, you can just spend money on ads”, I remember thinking.

As a startup founder, nobody cares about your product. Actually, no, it’s worse than that: everyone is actively disinterested in your product.

…it’s worse than that: everyone is actively disinterested in your product.

Your customers are bombarded with so many ads and false promises every day that their croc brains will actively filter you out even before reading, let alone considering, your proposition. As a startup, you don’t have brand recognition or distribution channels.

In short, user acquisition is hard. The whole word-of-mouth / virality trope is nowhere as easy as it looks from the outside. Startups are incentivized to pretend like their companies took off on their own. The reality is that companies take off because the founders make them take off.

So how did I get over it? It’s a journey. For starters, I read Traction, which helped in the same way that a stranger telling you “Yes, this totally sucks for everyone” helps: psychologically, but only a little bit.

Lots still to learn here.

#2 coding & other actually useful skills

As a PM, I always prided myself in defining the Why and the What but never the How. I was great at it! So good in fact, that I never actually learned how to do anything useful (like coding, designing, or marketing). Specialization is for insects, right?

Wrong. As a startup, you’re too poor and too early-stage to attract great talent to do the “busy” work. All you really have is passion and work ethic, and money can’t buy that.

As a startup, you’re too poor and too early-stage to attract great talent to do the “busy” work.

Also, you can’t get away with the level of quality that larger companies have. You can’t hire a contract developer and expect them to check their own edge cases. You can’t hire a content writer and expect them to pour their heart into a blog post. You can’t hire a salesperson who’s going to follow up 8 times until the user either buys (or dies), like you’ll need. In the beginning, it has to be you.

#3 psychology

As a PM, I always had external validation. If my product wasn’t doing well, there was always a long list of confounding variables and external factors I could point to. Whether it was HIPPO, or simply company politics, I always had a psychological escape hatch.

As a founder, you have none of that. Everything wrong with your startup is your fault, and nobody cares about why. Every day, you paddle against the current of your startup turning into a shrug and a dinner party story. The only thing that can stop that is you.

Everything wrong with your startup is your fault, and nobody cares about why.

I’ve had mood swings unlike anything I’ve ever experienced in a job. To survive psychologically, I think you have to be doing it for a reason besides venture-capital-sized return. You have to actually believe in your mission. It’s the only thing that’ll pull you through.

Jokes aside, I love building Keeper. If you’re a PM considering taking the plunge, I hope this was a helpful perspective.

This story is published in The Startup, Medium’s largest entrepreneurship publication followed by +427,678 people.

Subscribe to receive our top stories here.

3 ways being a PM didn’t prepare me for starting a company was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

A new journey — building Keeper Tax

👋 Hi friends, we’re starting a new business. Wish us luck!

Today is officially the first day of the rest of our lives! Just kidding. We’ve been at it for a few months now, I just hadn’t gotten around to posting about it.

What’s Keeper Tax

Keeper is a service that automatically finds tax write offs for self employed people. We do this by monitoring your bank statements with computer algorithms. Check us out >

Why taxes‍? Sounds boring.

Nope, taxes are awesome. Taxes are like someone offering you $1,000 per year in exchange for doing some research and writing stuff down every week. If that’s boring then please write me a check.

Also, this isn’t my first tax rodeo. Previously, I worked on Stride Tax — an app that’s helped 200k+ gig workers track their mileage and expenses write offs The experience of growing that app (and seeing so many people churn) made me realize something super upsetting: there are millions of 1099 contractors out there who are leaving huge amounts of money on the table (we estimate $1,320 per year, on average) because taxes sounded boring.

With Keeper, we’ve set out to build a solution for those people leaving money on the table. That solution needs to be far earlier than expense tracking apps today, and it need to be fun. Easy, right?

Why now‍

Self employment is becoming mainstream. Back in the day, self employed people were savvy small business owners. They bravely chose to forgo the traditional W2 route, knowing full well what it involved.

Today, platforms like Uber and Airbnb and are making self employment / 1099 contracting work much more ordinary, and much less intentional.

This new wave of gig workers don’t think of themselves as business owners. They don’t have “business expenses”, and they don’t think about what’s a tax deduction and what isn’t. Why would they?

For these folks, accountants are too expensive, and tax software is too much work. There has to be a better way.

What’s next

Not much — we’re almost done here (just kidding).

We have a lot ahead of us. The space is hyper competitive and, there’s a certain company (rhymes with “grintuit”) leading the pack. But whatever we build, we want to make sure it adds value to what already exists. Ahoy!

[this post originally appeared on the Keeper Tax blog]

“Documentation” is a dirty word — especially at tech startups, where it seems to go against every grain in our rebellious, “move fast and break things” brains. Documentation, we say to ourselves, is for historians. Everyone on my team is already aligned, we tell ourselves, so why waste time on writing it down.

Wrong. Documentation is sexy. It’s a core competency of effective product management. I would so far as to say, it’s the most important job a PM has. As much as we PMs like to think of ourselves as “CEOs of the product”, a large part of being successful is embracing our role as “glorified note takers”.

Good doc / Bad doc

A lot of PMs are resistant to writing docs, because they’ve been burned before. The docs they know are lifeless walls of text that sit around and collect dust. It’s easy to see why the idea of spending the time to write that kind of doc is unappealing. Not all docs have to be this way.

A good doc is written to be read. It’s acutely concise. A good doc is well formatted, and can be read and understood in three minutes, by anyone in the organization. It avoids jargon, and either provides business-level perspective, or links to it. A good doc takes the time to outline non-objectives and risky assumptions. It challenges the reader, and pulls out underlying disagreements for discussion.

A bad doc is written to be written — a checkbox on a todo list. It uses sprawling sentences of vaguely agreeable sentiments, and sloppy formatting, to dissuade readers from engaging with its contents. A bad doc is written to protect the writer from dissent, and is a waste of everyone’s time.

The power of a good doc

If your organization has more than two other people working together, creating a culture of writing good docs is probably worth your time. There are two reasons: (1) good docs are a lightweight way to elevate decision quality, and (2) good docs allow product teams to scale.

(1) Good docs elevate decision quality

Most PMs are optimists — they have an idea, they get excited, and then they execute. Passion is great, and execution feels productive, but it’s incredibly wasteful when the initial decision was not made with enough intentionality.

Kicking off off a project with good doc template forces us to step back and be intentional. Even the biggest rockstar PM on your team sometimes forgets to specify non-objectives before kicking off a design cycle, sending their designer off on a goose chase. It’s the same idea behind Checklist Manifesto — why force yourself to remember a processes that could be systematized?

Also, knowing that your written words will be read by others in the organization raises the bar. As the writer, knowing that you won’t be in the room when your words are interpreted by your superiors and co-workers, forces you to uncrumple your thoughts and intuitions in a highly productive way.

(2) Good docs allow product teams to scale

People think very differently. It’s amazing how easy it is for a group of people to leave a meeting thinking they’re in agreement, only to discover (later) a misalignment that slows execution and erodes trust.

A well-written doc is like creating a hundred (super eloquent) copies of yourself. The combinatorics of 3+ stakeholders spins out of control very quickly, and even the most extroverted PM can’t expect to insert themselves into every possible conversation to make sure folks all have the same assumptions in mind. Good leaders repeat themselves, and a good doc supercharges that ability.

Good docs also enable efficient asynchronous communication, killing unnecessary meetings and freeing people’s time. Reading a good doc takes three minutes, and allows the reader to choose whether to invest further by commenting, or to move on to other work. Discussions within docs are contextual, efficient, and centralized. Discussions in meetings tend to be inefficient for everyone except the asker and responder.

How to write good docs, and create a culture where it’s the norm

Writing good docs is hard, and there’s no one-right-answer. Below is an overview of how we tackle the challenge at Amplitude Analytics .

Page limits enforce clarity. Writing a good doc should be hard. Long, winding, sentences are generally reflection of a lack of clarity. If the communication can’t effectively fit on one page, it’s a sign that the PM should probably go break down the problem some more.

Templates save time. It’s a lot less work to delete a section in a template, than it is to remember to add one. It’s not condescending, it’s efficient. Having simple sections that remind the writer to start with the high-level context, and to be explicit about metrics or risky assumptions, facilitate clearer writing and decision hierarchy.

Formatting elevates quality. It’s like the broken windows theory where people are more likely to litter in a neighborhood with broken windows. Docs are the same way — a sloppily formatted doc makes the writer more likely to wing it. Take the time to create a template with nicely formatted sections, tables, and doc headers. It’s a one-time investment that pays dividends.

Comment, comment, comment. There’s no better way to de-motivate your team from writing good docs than to not comment on them. Comments don’t have to be particularly insightful, they just need to demonstrate engagement, and to set an example. Ideally comments are delivered in a digital way so that others in the organization can asynchronously benefit from the discussion, but I’ve also seen the print-out-and-put-on-your-stakeholder’s-desks method work.

Doc types should scale according to your organization’s needs. As more stakeholders become involved in the product development process, you will need to split out communication into more docs (especially if you want to keep the one-page ‘conciseness’ requirement).

Docs docs docs. If you’re part of a similarly doc-obsessed product team, I’d love to hear from you — leave a comment below!

How to write sexy docs was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

How we do it at Amplitude, and why you should start doing it too

One of my most favorite books related to product management is Lean Analytics. Most famously, it outlines the role of data in the build -> measure -> learn product development cycle, and what makes a good metric.

A less well known concept discussed in Lean Analytics is a process in product development that they call ‘drawing a line in the sand’. The idea is simple: before you release any new product or feature, set a measurable target that will determine whether or not the release was successful.

When I first read about all of this (I was graduating college at the time), it sounded simple enough. Yeah, sure — set a target, check if you hit it, makes sense. And yet, I’ve seen very few product teams actually do it. Empowered product teams might set quarterly business-wide OKRs and measure themselves against that, but I rarely see this practice applied down to the level of a feature release.

What happens instead is what I like to call Fun Facts. A Fun Fact is a contextless number generated after a release that makes people feel good at the cost of obfuscating actual success measurement. For example: “Over 4,000 people have used this feature already!” or “Awesome funnel conversion so far — 60%!”

These types of stats often get quoted in weekly standing product meetings, and everyone looks around and says “interesting!”. At best, Fun Facts are irrelevant. At worst, they spread as a meme within the company, get quoted by executives at company meetings and with external partners, and contribute to shaping misguided product strategy.

Why set metric targets for every product release

One of my favorite quotes in Horowitz’s Hard Thing about Hard Things is “All decisions were objective until the first line of code was written. After that, all decisions were emotional.”

It’s true — as soon as something moves from critiqueable design mocks to engineering requirements, it becomes a lot harder to admit failure. Nobody wants to tell the engineers and designers that nobody is using the thing they spent weeks working on. That’s exactly why, as a product manager, you should insist on setting metric targets before that first line of code is written.

At a high level, three things happen to a team that sets product performance targets:

Setting product metrics builds team alignment

Making metrics a core part of the release process builds focus. It’s always easier to have a discussion about design, or development release timing decision, when everyone in the room agrees on why this thing is being released in the first place.

Agreeing on a target is an amazing way to resolve design disputes and keep moving forward. Disputes like this generally come from a misalignment on goals, so being specific and quantifying what success looks like gives folks the right context for making decisions about pet features or design minutia.

It builds autonomy

The practice of setting and communicating metric targets before a release builds trust and autonomy for your team. It’s the same idea as why you should set OKRs. It helps ensure that your team has the space to come up with the right solution to a problem, rather than the solution which most closely matches what executives think might solve the problem. It builds company-wide trust through accountability, and ensures that your team has space to breathe.

It introduces accountability

Setting metric targets introduces accountability into product development, reminding us all that we’re building for customers and that only the customer, not the designer, engineer, product manager, or executive, will determine whether it’s successful.

It also ensures that the product development team is thinking iteratively. Every time you commit to a metric, it should be an uncomfortable experience that makes you think: “Okay so what do we do if we don’t hit this?” This attitude empowers the designer to start thinking ahead to the V1.1 iteration, and for the engineer to build-in more code abstractions enabling the team to iterate faster.

Example of how we set product release targets at Amplitude

Last month, our team set out to add user profiles to Amplitude. The idea was to lay the foundation for building more social validation into the platform. We wanted to make building charts and dashboards in Amplitude feel more personally rewarding, and introduce additional search traversal routes for analysis consumers.

The design kicked off with a product one-pager (similar to Intercom’s Intermissions), where we set a high level context, development scoping, and non-priorities. After a few rounds of iteration with the team, the designer came back with these mockups:

Defining the metrics

Defining good metrics is an art, but, logistically speaking, we created a simple spreadsheet with two sections. The first section is for primary metrics, which are designed to be overall success indicators. If we don’t hit these, we should go back to the drawing board with the release and re-examine our core product assumptions. A secondary metric is meant to validate smaller design decisions made. Missing a secondary metric means we should make adjustments to the design, but doesn’t indicate overall release success or failure.

Setting targets

Using the above spreadsheet, we sat down as a product development team (design, engineering, pm) and set the success metrics together. As we went down the list, we would discuss the closest proxy metric, decide on a target to commit to, and briefly mention what we’d need to do if the target wasn’t hit.

For example, we set a target of 10% for the percent of daily active users would visit their own profile page. We proxied this metric by looking at an existing analogous feature usage where you could use our search feature to find your previously created content. Given that the new profile page was designed to be more valuable and more discoverable, we decided to set this target somewhat aggressively — about 50% higher than the proxy. If we don’t hit that, the designer suggested that we might think about changing the link color to blue, making the hover state more engaging, or we might have to go back to the drawing board entirely.

Another target we set was that 20% of the time when a profile hover state was enabled, the profile should have a photo. The design had a prominent avatar photo placement on the hover state, and this was a topic of heated discussion during the design iteration process. Setting a target together with engineering and design built alignment and removed the politics from the decision. Now, we knew that we’d need to make an adjustment to the designs if we couldn’t get enough users to upload photos to justify the prominence of user photos product-wide.

Post-release activities

Having set the targets up-front, it was very easy for me to prepare a reporting dashboard upon release. Folks felt ownership over the numbers, and it was exciting to see the numbers come in against our targets.

Rather than reporting Fun Facts, the team felt proud and empowered by the data. It also made product reviews extremely easy to prepare since I already had the metric targets, and could trivially provide an is this good or bad perspective. In short, setting metric targets before development front-loaded a lot of the analysis work we’d have to do anyway.

— —

We’re excited to start setting metric targets more consistently for every release at Amplitude. We think it’s the right kind of process — it builds accountability and drives business alignment on the product development team without enormous overhead. As always, we’ll keep adjusting as we learn.

If you’re a product manager setting metric targets as part of your releases today, we’d love to learn from you!

If you enjoyed this post, feel free to share it with your network and to learn about other practices that we believe are key to winning in the product-led era, like low-friction user research after a release, and naming conventions for event logging.

User research process for startups

Forget the 8-step process, just go talk to them.

A traditional user research process might look like this:

1. Write up an agenda
2. Draft an invitation template
3. Find an analyst to help pull a list of user emails
4. Send the invites
5. Deal with email threading to schedule calls
6. Deal with cancellations and rescheduling
7. Write notes
8. Juggle payments

What a drag! In order to get in front of users regularly with that process requires dedicated user researchers. At startups, we don’t have that luxury.

Below is an overview of how I’ve learned to do user research at startups. It’s helped me eliminate any excuse to not get in front of users regularly, and make sure that I, and my team, are never flying blind as we build product.

Hack #1: Forget a detailed agenda — have a learning objective, and follow good practices.

Let the user drive the discussion, and ask why repeatedly until you get to a root cause. If your agenda is a list of questions, and your plan is to just go down the list, then you could have just sent a survey. Let your user research subject guide the conversation and if they don’t bring up your pet feature or pain point, maybe that’s a sign that it’s not as valuable as you thought!

Hack #2: Pull the user research subject emails yourself — don’t let yourself be blocked by a data analyst.

Too many product teams still treat analysts and data scientists like human-interfaces-to-sql. The time it takes you to write out a request, and deal with the internal back-and-forth, is time you could have spent elsewhere. Instead, use a product analytics tool to do it yourself. Tools Amplitude let you identify the users who engaged with a particular feature that you are interested in and filter based on other demographic attributes. Below is an example screenshot of how we use Amplitude Analytics (at Amplitude) to identify a group of users who signed up in September but then didn’t come back in October.

Hack #3: Forget fancy email platforms — just use bcc in your personal email.

A small user research email blast doesn’t need to be sent from your company’s email platform, and doesn’t need approval from the outbound team. Your personal email will likely get more clicks anyway. Plus, this process scales easily: you can bcc up to 100 people at a time and you can modulate the compensation and call duration as needed. The below email template got 12% conversion to a scheduled call:

Hack #4: Use a calendar scheduling tool to avoid the back-and-forth.

Calendly, Mixmax, and Google Calendar all offer the ability for a recipient to pick a free time on your calendar. These tools connect to your work calendar so the interviewee can easily select a time slot where you’re free and automate the calendar scheduling and reminders for both parties. Pretty awesome.

You can also edit the calendar event so it links to a permanent video conference via a tool like Zoom, or Google Hangouts. Example below:

Hack #5: Get a coworker to take notes.

Taking notes is something you can’t skip out on since you need them to ensure that the user insights scale company-wide. But asking questions, listening to answers, AND taking notes all at the same time is a lot to handle. Ask someone to join you and take notes while you drive the research so that you’re not stuck trying to remember and summarize it all later.

Hack #6: Keep a Hero panel.

Your Hero panel are your users who love your product and are enthusiastic about giving feedback. At Health Stride, our heroes were quick to hop on a call to outline bug reproduction steps, and invaluable when getting feedback on power-user feature improvements. Offering folks a spot on your Hero panel gives you an outlet to get feedback even faster in the future. Collect their phone number and text them when you need quick thoughts, or put them on a Google group and have your designer email them with in-progress designs. It’s not a replacement for outbound user research, but often times speed matters more.

Hack #7: Automate the whole process.

Use your email platform or product analytics tool to set up a triggered research invite email with a calendar schedule link. You can set one up to send to some percentage of users a few days after they signs up, or after they interact with a particular feature. It’s magical to see user research calls show up on your calendar automatically.

Those are my hacks. If you have your own, please leave a comment — I’d love to hear about them!

Stop putting off user research. 7 hacks was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

These days, it seems like every analytics tool is clambering to new heights in data visualization and predictive analytics. Whether it’s Mixpanel’s Signal which “finds hidden gems buried in your data automatically, so you can skip the complex math and act on insight quickly” or Amplitude’s Compass which “scans through all of your user data and reveals which behaviors lead your users to stick around long-term”, everyone seems to be very concerned about me wasting my time on complex math and predictive analysis.

For those of us who have been in the analytics logging trenches for a few years, we can’t help but roll our eyes. I wish those were the problems we had. Instead we have these problems:

• Mobile sends an event called “Signed up”, but I think web calls it “signup”. Or was it “Account create”? Regardless, we’ll just have eng pull that from the database because nobody trusts that data.
• Only Katie on the finance team knows what filters you need to apply to the “Purchase” event to get MRR, and she’s out this week.
• Folks on the marketing team use Google Analytics, which over-reports Mixpanel by about 20%. But that’s because it’s hard to know what the events are called in Mixpanel, only product knows that stuff. I’m sure the board will understand.

Each of the above examples is painfully real. Not having my product’s magic moment discovered automatically, is not.

A practical guide to analytics event naming conventions

The primary thing you’re trying to achieve with analytics event naming conventions is discoverability and understandability, at scale. The original PM + engineer working on a feature may remember that “click help button” is sent when the user presses the question mark in the 3rd step of the purchase funnel, but nobody else will. And things will get dicey when someone else in the company builds a another help button.

Step one is to define a rigorous set of grammatical rules. You’d be surprised how many different ways there are to describe a sign up event: Signed Up, Sign up, sign up, signup, account create, etc.

Below are the naming conventions we use at Stride.

All event names should be…

• Title Case
• Present tense
• action word first, object word second

Now, what happens if you now sell two types of insurance: health and dental. Should you put that information in the event name, or within a property of the original purchase event?

At Stride, we embrace event properties. If we think we’re likely to want to compare two events, like how many people purchased dental vs. health insurance from us, this will be much easier if those are just properties of the same event. So our rule is: when in doubt, make it a property.

Sometimes, it doesn’t make sense to hide information in an event property because it needs to be easily searchable. Say, for example, you’re wondering what events are being tracked on the homepage. In that case, rather than hiding that information as a property for “button click”, it make senses to add a searchable Category to all homepage events.

As your company continues to scale, you can also add sub-categories, formatted like this:

Putting it into practice

Much more important than what you choose as your company’s analytics event naming conventions is actually making sure it’s followed.

At Stride, event logging is an explicit part of the feature development process. We use a single Logging Dictionary (google spreadsheet) to spec out all events for every new feature — just add a new sheet. This enforces conformity in naming because it’s easier to just copy the previous features logging than it is to think up new names. We also try to centralize conventions by anointing a Data Democracy Champion to review all logging that gets implemented company-wide.

If you’re a founder or early employee looking to set up excellent logging standards at your startup, I hope that the above guide will help. Want help? DM me.

Stride uses the Uber Driver API to help driver partners keep 21% more of their earnings

Editor’s Note: The following is a guest blog post by Paul Koullick, Product Manager at Stride.

Meet Alice, a new driver partner with Uber. This is Alice’s first time working independently.

Alice knows that, as an independent worker, taxes won’t be withheld automatically from her earnings, and heard from a friend that she should be setting aside about 30% to cover her tax bill. Then using Stride to track her earnings and business expenses, Alice found that she only needs to set aside about 9% of her earnings for taxes — 21 percentage points less than she expected. To date, driver partners like Alice have used Stride to claim more than $60M in tax deductions, reducing their taxable income and helping them keep more of their earnings.

Here’s how this is possible: A 30% effective tax rate is a commonly used rule-of-thumb for independent contractors. This rate combines federal, state, and self-employment taxes, while making some assumptions about household size and income bracket.

But 30% of earnings is far more than Alice should be paying in taxes. What Alice, her friend, and most other driver partners don’t realize is the jaw-dropping amount of money they can save in taxes by deducting business expenses and miles driven for work. As an independent contractor, Alice can actually claim tax deductions for many of her day-to-day expenses: The miles she puts on her car, the new phone and car holder she’ll need, her monthly health insurance premium, and her weekly car wash to name a few. Most driver partners simply aren’t aware of everything they can deduct.

The financial impact for driver partners who track these deductions is significant. In a recent survey, we found that driver partners who track these business expenses don’t need to set aside anywhere close to 30%. In fact, the typical driver partner using our mileage and expense tracking app Stride Drive can easily claim so many deductions that they owe just 8.7%. Compared to what driver partners who don’t track expenses would owe, their tax rate is 21 percentage points lower — keeping significantly more money in their pockets. That’s huge.

Helping driver partners see the financial impact of tracking deductions

Most driver partners don’t track their business deductions. People think it takes too much effort or time, and don’t realize how much it can impact their bottom line.

That’s why Stride built the Tax Calculator. With just a few clicks, Stride shows driver partners how much they should expect to owe in taxes and how much they could stand to gain from tracking more deductions.

As our CEO Noah Lang describes it, “Stride’s partnership with Uber is an unrivaled opportunity for us to deeply integrate products to serve driver partners throughout the year. I’m especially excited about how we’re using the Uber Driver API to provide any driver partner the simplest way to estimate their expected taxes.”

How we built the Tax Calculator using the Uber Driver API

Stride uses the Uber Driver API to retrieve an entire year’s worth of earnings and trips data for a driver partner. The Tax Calculator parses apart the various payments, removes basic deductions like fees and on-trip mileage, and gives each driver partner a simple tax summary of their earnings and estimated taxes.

In order to generate each driver partner’s annual tax estimate in real-time (10–15 seconds), we parallelize pulling data from the /partners/payments and /partners/trips endpoints to aggregate annual earnings data including incentives and referral payments, remove on-trip mileage deductions, and unify the result to present it in a way that’s helpful to the driver partners.

Year-round, we’re showing driver partners how much of their earnings they should set aside, so when tax time comes around, driver partners are financially prepared and understand how to keep more of their earnings.

We’re thrilled about this first integration with Uber’s Driver API. We’ve already generated tens of thousands of tax summaries, and helped driver partners claim more than $60M in tax deductions. In partnership with the Uber API team, we look forward to continuing to stitch together our two products to support driver partners with a full suite of benefits that puts money back in their pockets.

Stride Health is a growing suite of benefits for independents, connecting independent workers with health insurance, healthcare and tax compliance support. Our mission is to empower the 53 million independent working Americans to take control of their physical and financial health.

Based in San Francisco and available nationwide, Stride Health launched in early 2014 and is venture-backed by leading health and consumer finance firms Venrock, New Enterprise Associates, and Fidelity’s F-Prime Capital.

*Stride Health is not a personal tax advisor. The information above is meant only for guidance purposes and not as professional legal or tax advice.

**Uber does not give legal or tax advice.

⚀ To get updates from the Uber Developer team in the future, follow our publication or follow us on Twitter.

⚀ Please tap or click “♥︎” to help to promote this story to others.

Stride + Uber: Helping driver partners get the most out of every mile was originally published in Uber Developers on Medium, where people are continuing the conversation by highlighting and responding to this story.