Noah Brinker

Product Management, Growth Marketing. I like to build things.



  • Arsenal Football Club

  • Arkansas Razorbacks

  • Coffee Roasting

  • Soccer/Futsal

  • Disc Golf

<- Back Home

<- Back Home


  • Created a multi channel marketing campaign that led to Shark Tank appearance (Season 10 Ep. 3)

  • Acquired initial 100+ beta users for crypto investing app through ASO, Social Ads, and Content Marketing


<- Back Home


  • Created a multi channel marketing campaign that led to Shark Tank appearance (Season 10 Ep. 3)

  • Acquired initial 100+ beta users for crypto investing app through ASO, Social Ads, and Content Marketing


<- Back Home

<- Back Home

Product Requirements Example: Baremetrics

As a practice in Product Management, I occasionally try to document the work needed to create a new feature if I were in charge of building a product. The process I generally abide by includes ideation, research, gathering requirements, and writing user stories for development. In a previous post, I showed how I would create a new feature for Moonlight. I'm also a huge fan of Baremetrics and enjoy following their progress, so I decided to do something similar.

When going through the process of creating a new feature, I normally include 4 important pieces of information:

The problem that's being solvedWhy we should solve itAcceptance criteria-what makes this story complete?Metrics that should be tracked
The Example

For Baremetrics, I started by researching the demo page on their website, which you can see below. They use this as a way to share their own metrics as an open startup, but also as a way for potential customers to see a demo of the product before signing up.

This is the page Baremetrics created to display their own metrics and give potential customers a demo

I wanted to start with this demo page because it gives me a lot of insight into the product without needing to speak to Baremetrics or current customers. If I were working on Product at Baremetrics I would most likely be talking to customers for ongoing research to improve the product anyway, so let's pretend I had met with 20 customers over the previous month and came up with 3 potential ideas for new features:

1. Add a custom field to a customer page for a user to add any piece of information they want
2. An email trigger to a user when a customer with a LTV > $XXXX churns
3. Add an email field to the Free Trial banner on the demo page

Let's also pretend that the top 2 features were requested by 10 customers each. These 2 would directly add value to users and help them with their business. The third feature would be more of a growth feature that we could potentially A/B test to see if an email field would increase sign ups and ultimately paid users from the demo page.


This is the point where I would do some more initial research to see which (if any) of these should be prioritized. First I would look at the current data that we have to see what insights I could gain. For #3, I would check to see what the current conversion rate is from # of Demo Visitors -> Sign Ups from the Demo Page. The other 2 features would be difficult to get insights from. Perhaps I would check to see the number of times a user views the customer page of a customer who recently churned with a LTV in the top 10% of their customers. My hypothesis is that by viewing the customer, they are likely trying to understand more about why they churned. All of this information could be confirmed by understanding the customers better through more research (ideally in person or over a call).

For this exercise I'm going to focus on aspirational product goals that can move the needle for customers and potential customers. Adding a custom email field or increasing sign ups from the demo page would certainly benefit Baremetrics and its users. But churn is a huge issue for SaaS and subscription companies, and automated payment recovery is a key add on of Baremetrics. This feature has the potential to save users thousands of dollars per month by recovering failed payments. (It's possible this feature already exists in Baremetrics, but I'm not currently a user and don't have a way to confirm)

The problem that is being solved by this is that churn has a large negative impact on MRR. Companies often don't have visibility to track churn and aren't able to recover failed payments, even if the customer wants to continue. We should solve this because reducing churn increases the ROI and gives companies another reason to sign up, continue as a customer, or become an evangelist of Baremetrics.

(prototype built using

I'm not able to see the settings page on a Baremetrics account, so I decided to create a prototype lo-fi of the homepage using I'm envisioning in the notification settings having an option where a user can choose to receive an email when a customer churns and the ability to specify the minimum LTV of a customer that they want to be notified of. Here are the user story and requirements for the feature.*

As a Baremetrics user I want to be notified of churned customers so that I can personally reach out to them and reduce my churn.

In the notifications page, a user should be able to choose to be notified each time a customer churnsThe setting should include optional conditional settings based on the LTV of a customerWhen the notification is selected, the user can (but does not have to) select to be notified based on the LTVWhen a user chooses to be notified based on the LTV, a dropdown should appear that includes "All Customers", "$1,000+ LTV", "$2,000+ LTV", "$5,000+ LTV", "$10,000+ LTV", and "$20,000+ LTV"When a user chooses the selection, they should be notified by email each time a customer churns based on the selected LTVThe email design should follow the same design as other notification emailsThe email should include the name of the customer, the contact name, and the contact email
The last part I want to discuss are the metrics I would want to track for this feature. When customers succeed, Baremetrics succeeds. For this reason, I wouldn't want to track anything related to the number of emails sent or the amount of customers that sign up for notification emails. Instead, I would want to know more about how we've helped Baremetrics customers. Here are the metrics I would choose:

The total MRR saved from a LTV Churn Notification EmailThe number of failed payments that have been recovered after the LTV Churn Notification Email
If this were an actual feature I was looking to build, I would gather more detail about the customers who have requested this and the use cases behind it to articulate the reasoning. I hope you enjoyed this. If you have any questions or thoughts I'd love to hear it!

*Unfortunately I don't have access to view the settings page to fully detail the requirements, but I did my best to include the right details for this hypothetical feature.

<- Back Home

Product Requirements Example: Moonlight Work

In this post I'm going to talk through how I would document the work needed to create a new feature for Moonlight Work. This will include ideation, gathering requirements, and writing user stories for development. Documenting this is useful for keeping all information together in a single place. It should be accessible by designers, developers, and any other stakeholders who might need to know the information. There are various formats that people use to create these-personally I like to keep it simple. Complex products typically require more complex process, but I typically try to include 4 basic pieces of information:

The problem that's being solvedWhy we should solve itAcceptance criteria-what makes this story complete?Any metrics that should be tracked
The Example

For this example, I'm going to start with ideation. I had created an account with my company to see what a company sees when searching for developers. After some looking through it from the eyes of a company, I noticed that developers are searchable by Technology, Location, or Type of work (Full Time or Contract projects). These are great filters and necessary for companies to be able to find the right developer for their project or team.

(gray boxes added to hide names)

While looking at this page, I wondered if companies would want to sort developers based on the amount of hours they have worked through Moonlight. The information is available and is part of the developer's profile. My assumption is that companies would feel more comfortable hiring a developer who has a proven track record of working with Moonlight and has experience managing a project through the product. This is typically where I would get in touch with users or potential users and run some interviews to determine if this is a need for companies who are looking to hire. Unfortunately I don't have the ability to speak with anyone, so for this post I'm going to assume that I did 15 interviews with companies that are actively hiring and validated that this is a pain point they have. (Soon I will write a post on how to run customer interviews) Let's also assume that companies typically wanted developers who had at least 10 hours of experience on Moonlight or developers who had at least 50 hours of experience on Moonlight.

This brings me to the next part-Why should we solve this? This is normally answered by qualitative data (user interviews, surveys, etc.) or quantitative data (product metrics, A/B testing, etc.). In this case, I would perform user interviews to determine this feature would bring value to users. If possible, I would also view metrics for how a user interacts with the search function.

Do they filter, click into a developer's profile then leave?If so, why do they leave? What information are they looking for?Is there any information missing in the filter view or in the developer's profile?
These are the types of questions I would try to ask and understand before building this feature.

Now that I've "validated" my hypothesis, I'll create a prototype to help explain the feature idea to the team. Below is an example prototype I built using This is where the details of the problem and proposed solution would be discussed. Part of the goal here is to introduce the team to the feature to gather ideas and feedback. The other part is to begin documenting acceptance criteria of what would make this feature complete.

(prototype built using

As you can see, I want to make this as close as possible to how the feature will look as part of Moonlight. Unfortunately has some limitations and I wasn't able to create exactly what it will look like. I would also consider using a prototyping tool like Sketch or Figma.

This is when the details of the feature need to be really fleshed out. The more detail that I can include in these requirements, the less confusion there will be for the team building it. This is especially important for asynchronous teams who rely on clear communication. Here are the requirements and user story for this feature:

As a Company hiring developers on Moonlight, I want to search for developers based on the amount of hours they have worked through the Moonlight platform.

On the search page that companies use to search for developers, there should be another filter option available to search by hours workedThe design should match the other filters, but the text box should be a clickable drop downThe text above the text box should be "Hours worked"When a user clicks in the text box, they are presented with a dropdown selection to choose a minimum amount of hours workedThe options available to choose should be: "0-10 Hours", "10-25 Hours", "25-50 Hours", "50-100 Hours", "100+ Hours"When a user chooses any of the options, the developer results should filter based on their selection (i.e. A developer with 12 hours worked should appear when the "10-25 Hours" option is selected. A developer with 60 hours worked should appear when the "50-100 Hours" option is selected.When an "Hours worked" filter is selected, no developers outside of the selection should appear
The last part of this feature will be metrics to track. Understanding how your products are used is vital to finding product-market fit. Without this information, you are flying completely blind to the most important part of your company: your users. Here are the metrics I would want to track for this feature:

The amount of times the "Hours worked" option is filtered and usedThe amount of times a developer is hired immediately after the "Hours worked" option is filtered and usedThe Total $ amount spent on a developer after the "Hours worked" option is filtered and used
This is the basic process I use for creating a new feature. Each step is an important part of creating a new feature. It starts with the user-their problems and needs-and comes full circle back to the user in the form of new valuable features.

I hope you enjoyed reading this through. If you have any thoughts or feedback I'd love to hear it!