Preference management is an integral part of a great notification infrastructure, which makes it a very important piece of the puzzle here at Courier. This also means that there was a lot of learning and experience-building opportunity for the intern on the project, Denis Tatar. Denis’ internship was only a few months long, but he was able to make an enormous impact as the product manager for Courier’s Preferences feature.
We wanted to learn more about Denis’ experience, so we asked if he’d be willing to work on a writeup for us. Then what he came up with was so good, we thought it would be a good idea to share with all of you! This post will cover Denis’ workflow from planning to execution around the Preferences project as well as his experience working with the Courier team specifically. We’ll let Denis take it from here!
What was the problem?
The problem we experienced at Courier was that we’d offer Preferences (V3) to our customers, but the entire product feature’s strategy wasn’t fully fleshed out. I believe that V3 was a great stepping stone for V4, but fundamentally had flaws in certain parts of its strategy. Allowing only global opt-in/out is an example of this. Another problem was that V3 didn’t gain much traction, which I believe points back to the lack of a fully thought out strategy. In May, Preferences (V3) would only allow users to opt-in and out of their preferences of choice globally. V3 of Preferences only allowed our customers (and their customers) to opt-in/out of notifications, and customers globally could also decide if certain notifications were required or not. V3 helped give our customers the ability to start playing around with the idea of having preferences. However, globally opt/in out is a problem because it constrains end users’ notifications options. It was either all or nothing, no in-between. Similar in theory to the Pokemon saying, “Catch one, catch them all.” A problem with this, though, is inbox flooding. Global opt-in would allow for the concept of the end users’ inboxes becoming flooded with every product notification which is problematic because it can easily drive users away from your product.
Global opt-in/out was quickly resolved by allowing users to select what content they wanted to be notified of and the channels they’d prefer. This overall trend in the market is used by thousands of companies (B2B and B2C products), especially in the technology space.
Visibility became a serious issue with V3. End users never had the option to select what type of content and channel they wanted. Users would be asked if they were interested in receiving notifications in general. Not offering options is problematic as it constrains visibility on what you’ll receive through notifications. End users also don’t like surprises when it comes to product notifications. Having clarity is key because it enables end users to have control over their notifications.
With V4, we solved the visibility problem, which was the main “fail” from V3. Our customers and their end users now had the ability to control the content they received and the channels they would prefer.
V4 was a good way to strategically notify end users.
Plan
There were three phases we followed as a team when building Preferences.
1. Research
In phase one, I spent a decent amount of time looking at what is currently available in the market in terms of preference centers. I would constantly ask myself the following two questions:
“How does [insert company name] manage notifications? What does their preference center look like?”
These questions were key. They helped me dive into necessary research which helped me pick up on many important market trends. Out of all the trends found though, there was one that stood out the most.
2. Trend: Channel & content selection through a toggle/grid style layout for preference centers is a must have.
This trend became the backbone to our summer project. It was important to offer users preferences options.
During this phase, I read many case studies. I was surprised to see how many existed on this topic. Each one helped enlighten me with solutions for the problem we were tackling. I learned through other people’s mistakes, absorbing the valuable lessons.
Talking to customers was extremely helpful in this phase. I was able to hop on numerous calls with our customers and hear their perspectives on this problem. I would ask questions and show examples of what we had in mind for a solution. This helped tailor a POC. The better we understand our customers’ perspective, the easier it is to start designing something that they would use.
3. Designing a POC
I really enjoyed this phase. Watching research become an actual POC was incredible, and so fun. We took all the feedback I had gathered, then created several iterations of designs.
Once we created a POC, it was essential to go back to our customers and ensure that it was something they envisioned for Preferences. Our customers were also lovely people to work with, always there to provide their much-needed feedback.
Often, I would have a decent amount of brainstorming sessions with Ian. We’d look at our research and what our customers had to say, and combine these sources into a POC. It was an insightful process to be a part of.
This phase lasted several weeks until we finally landed on a POC that satisfied all of the customers we had spoken to since May 2022.
4. Building an MVP
Once we had a POC and fully completed designs, we began building our product feature. This phase taught me two vital lessons…
Being organized is extremely important.
and...
As a product manager, you need to stay one week ahead of your team.
While working at Courier and delegating tasks, I noticed that the more organized you were, the easier it was to work with others. My organizational skills would impact how clearly our designers and engineers understood our goals and individually delegated tasks. The more organized we were, the faster and more efficient we worked. Outlining the tasks our team needed to complete, and vocalizing why these tasks were necessary helped a lot. It brought clarity to everyone, including myself.
The second lesson here was given to me by our CEO,Troy. He taught me how important it was to think about the current and following week. Troy brought this up because, as a product manager, you want to keep your team informed on what projects and tasks are in the pipeline.. A product manager that isn’t in this mindset can quickly become a hindrance to their team. Taking on this mindset brought clarity and made me less stressed about our project. I would spend time planning each week,and estimating where the team should be at the end of each week (cycle).
These two lessons helped when we were building an MVP. We progressed through each week as a team, with each week’s tasks outlined, along with the weekly goals we’d needed to achieve. Working with the team at Courier was amazing, everyone was understanding and absolutely brilliant. What I loved the most was that everyone had an opinion. Engineers and designers would ask if specific tasks were priorities before building them, which allowed us to build the MVP and get it up and running quickly. These questions helped guide priorities and decision-making.
Execution: What I did exactly
Throughout this internship, every day was different. My week would involve speaking to customers, delegating tasks to our engineers and designers, and taking time to think ahead, two to three weeks ahead of the current week. I also worked closely with both engineers and designers, ensuring great synergy between both teams.
There were four core responsibilities that I embodied throughout my product manager internship at Courier:
Being the internal expert on what the market (customers & prospects) want within my realm of focus.
Being the internal expert on what my product feature already provides (and thus the delta to the above core responsibility).
The ability to prioritize the path that gets Courier from our current state to our desired state.
The ability to educate the rest of the company on the current product, the product being built, and our ultimate product vision so that everyone can be on the same page without being experts.
As the glue that ensures the team is working together on the right thing for the right reasons, their success is ultimately limited by my effectiveness in one and two. I cannot accurately educate teammates on what I don’t profoundly understand myself.
Troy was a fantastic mentor throughout my entire time at Courier. He brought these four core responsibilities to my attention, which became an integral part of my internship. What resonated with me the most was being the glue between all teams. At first, I looked at this concept and was intimidated by it. But, I had a blast easing myself into becoming this glue-like figure between teams. It definitely wasn’t something easy to pull off, but I enjoyed the challenge. I managed to make a lot of great friends along the way too!
What trade offs did I experience?
There were many trade-offs throughout my entire internship. The main ones I experienced were related to the following concept “make it work -> make it good -> make it fast,” which I often heard throughout my internship. There were many times when small features that could make our UI/UX stand out would actually slow down the team.
Trade-offs like these were necessary. They had me questioning whether we focus on the nitty gritty details, or do we put the feature aside and focus on making a product that functions and gets the job done? The latter part of that question was often chosen as our strategy. It’s tough to make these calls because you know the team can develop an outstanding product build with phenomenal UI/UX components, but our build must accomplish what it’s meant to do in the first place.
The main goal was to release our MVP, ensure we have customer feedback, improve any core features, and then focus on minor priorities that affect the UI/UX of this product.
What was it like working with the team?
I had a blast working with the Lifecycle team on Preferences. Everyone was so kind, and offered fantastic feedback. I’ve mentioned this numerous times around the office, and on calls with coworkers. Working at Courier didn’t feel like work; it felt like I was working on a side project with close friends. I genuinely think this is why I was able to produce the work I did at Courier, because of the environment. Courier is easy-going, extremely friendly, and results-driven.
Another thing I really loved about the team was that they always thought of me. If there were tasks that engineers or designers would do that was considered a ‘norm’ for them, they’d ask me if I’d like to give it a shot to see what it’s like. I have three examples of this.
When designing a specific tool tip for a part of the Preferences project, Ian (Senior Designer) during one of our calls, asked if I wanted a shot at designing a tool tip. This involved working with Frames in Figma, a concept I never worked with. I really enjoyed creating that tool tip. It made me feel included.
Every week the team would have our team Lifecycle planning meetings. We’d speak about tickets, and write them up. It was early on in my internship when Suhas (Senior Engineer) asked me if I wanted to try writing up several tickets on Linear. I was aware that this was something most PMs would normally do, but I had a lot of respect for Suhas for bringing this up, and was willing to teach me how to properly create tickets in Linear.
Once the team had something solidified for Preferences, I began to ask around internally to learn if there were any companies that would be interested in hearing about my project. Nathan (Account Executive), reached out to me to let me know about a customer interested in this product feature. Nathan encouraged me a TON when it came to communicating with this customer. I was able to step outside of my comfort zone because of Nathan’s encouragement. I’ve never gotten to speak to a customer before at any of my previous internship experiences, and I learned a lot about customers and the way they perceive Courier.
Note that these are just three examples from the many opportunities like this throughout my internship. I do want to give a big shoutout to Ian, Suhas, and Nathan. I appreciate you guys giving me opportunities to learn and grow, it means the world to me.
How did I work with designers?
I enjoyed working with Ian (Senior Designer). We’d have impromptu meetings through Slack’s ‘Huddle’ feature, (which was internally renamed to ‘Huggle’ because of a typo I once made that stuck). These meetings were really great for brainstorming and product design. Sometimes, Ian and I would have calls later at night because it was easier to come up with more creative ideas.. We’d have one to two hour sessions, and we’d come up with some really awesome UI/UX for Preferences. This is something I’ll never forget.
When working with Ian, I would try to make it as easy as possible. I would create a to-do list through Google docs or Slack, so both Ian and I would be aware of what needed to be completed every week.
During our calls, Ian and I would also talk about a lot of different topics not always directly related to work, which was great. This really helped build our friendship, making it so much easier to collaborate and come up with a clean UI/UX for Preferences. I often do a decent amount of product design outside of work hours, and Ian would always give me phenomenal advice on product design and on Figma!
How did I work with engineers?
I briefly touched on this, but when working with engineers, I would help create tickets, and organize what each week would look like. I helped our engineers whenever they were confused about anything related to Preferences, and would explain how I came up with specific names, why Ian and I would design certain parts of our product, and the goals behind these designs. Many of these answers came from my extensive research process with customers that were interested in Preferences.
While working with engineers, I learned a lot on how to properly break down tickets (eipcs) within Linear. I thought I had a firm grasp before working at Courier, but I learned a lot more after working with the Lifecycle team. The key to breaking down tickets is to be able to think about every single detail alongside engineers. Being in a small group while doing this was super important, because each individual helped bring up a very important perspective on how to break down tickets.
During my internship, Seth (Chief Technology Officer), Suhas (Senior Software Engineer), Christian (Software Engineer) encouraged me to speak to the Developer Experience team at Courier and show them our project. The main goal behind this was to test to see if the UI/UX of Preferences was intuitive, if the design made sense, and if the Developer Experience team understood the goal behind this product feature. I prepared a slide deck explaining our project in its entirety. This was a great experience because it helped me prepare on how to sell Preferences to our customers. Giving insightful presentations about products and “selling” your product to customers is such an important and overlooked skill for product managers. Speaking to folks internally helped me practice and refine this skill, as well..
How did I solve the problem?
Before V4 Preferences, customers weren’t given the option of choosing what content they’d like to hear about, and how they’d like to hear about it. With V4 Preferences, users now can voice their opinions on both of these matters. This new product feature makes it possible for customers to choose what they like, and want to hear about. Specifically through their channels preference.
Gone are the days of inbox cluttering and customers becoming aggravated with the amount of notifications they receive. Preferences minimizes the frustration that end users experience with their notifications.
Want to apply for a role at Courier? Check out our careers page. To check out what Denis helped build in action, request a demo here and ask to see the Preferences feature.
Top comments (0)