10 Takeaways from my experience at On Deck Product Management
I recently participated in the 8-week immersion for the first cohort of On Deck Product Management (ODPM), the On Deck program designed for product leaders. The experience included:
Fireside chats with thought leaders in the Product Management space (such as Shreyas Doshi, Gibson Biddle, John Cutler, Jackie Bavaro, Lenny Rachitsky and so many more)
Workshops on product management and career topics
Networking opportunities with amazing fellow PMs
I decided to write this article and share some of my takeaways from the experience. This is not a summary of everything I found valuable, but a reflection with some actionable frameworks and tips that anyone reading this could also apply or explore.
Before I jump into the takeaways, let me give you a little bit of context of what On Deck and ODPM is.
What is On Deck?
On Deck is an EdTech startup that, in their own words, is "Building a modern educational institution that redefines how community and learning come together. Being part of any On Deck program means you’ll have access to a community of world-class professionals."
They are on a 100-year journey to change modern education (ambitious, right?)
It operates under 4 key ideas:
Silicon Valley is a Mindset. The world has access.
How we learned has changed. Education is now continuous. We Learn to Build, so we can Build to Learn
Stanford organized, catalyzing, amplified Silicon Valley's ambition
On Deck is organizing, catalyzing, amplifying the world's ambition
It currently runs 20+ different programs in the entrepreneurial, creator, and career segments, each of which is custom-built for its audience.
There's a lot to explore on the On Deck topic and a lot of great essays were already written about it. I’ll drop some here if you’re interested in learning more:
Great article from Packy McCormick: What’s On Deck for On Deck?
Another great article that explores their Flywheel model: What’s On Deck for Business School by The Flywheel
What about ODPM? How does it work?
On Deck Product Management is a remote program for seasoned PMs, product leaders and founders with product backgrounds. The curriculum combines modern PM frameworks, case studies, and a community of experienced PM peers to help product leaders empower their teams and enrich your organization's product culture.
The Fellowship combines the following components for a holistic approach:
World-class speakers and workshops – industry leading guest speakers, interactive hands on workshops, live case studies.
Mastermind groups and peer-to-peer learning – intimate groups matched by product specialization to foster accountability, vulnerability, and accelerated learning.
Thought leadership opportunities – a space for Fellows to create, edit, review, and publish content together for the product community at large, and for their organizations.
Cross-fellowship collaborations – unique opportunities to network and learn with other Fellowships in the broader On Deck ecosystem (Founders, Designers, Investors, Fintech, etc)
Product career coaching – executive group coaching sessions created by former product execs specifically for high achieving product leaders.
See more about the program (and apply to the next cohort) here.
10 takeaways from ODPM
Ok, now that I covered the basics, here's my takeaways’ list:
1. Writing can supercharge your learning and career
Writing publicly is something that was not on my radar. When I used to think about it, a few things would come to my mind:
It's a lot of work! Especially when you're not a great writer like me (and you're not writing in your first language). It always felt like a full-time job.
There's a lot already out there. How to contribute with something helpful?
Very few people would be interested, so why bother?
ODPM helped me look at this through different lenses. Here's why you should write more:
It helps you think, learn and become smarter: Summarizing content you consume in your own words, creating frameworks and getting feedback is the best way to consolidate knowledge and expertise. Spending time writing about something will help you solidify concepts, make your arguments more sound, develop clarity of thought and unique points of view (even if you’re doing only to yourself)
A great form of networking: Sharing ideas and adding value can lead to serendipity and interesting conversations. Just look at what happens on Twitter: There’s a lot of connections and knowledge sharing between PMs, VCs and Entrepreneurs, for example. It's where people share insights and build communities. Like Packy McCormick says, it's where the Great Online Game is being played. Writing is a good way of getting into the game
A superior resume: Writing is a great way to summarize your work, expertise and areas of knowledge
A shortcut to expertise and credibility: Writing can be a way of proving you're good at something you have never done before. Also, a lot of organizations value writing. Expertise isn't the prerequisite to writing, it's a result
It's more important to have relevant and actionable information to share than being a great writer. And improvement comes with practice, so the more you write the better you’ll become.
Another curious personal aspect is that I work in a Publishing organization that leverages writing from colleagues to showcase the breadth and depth of knowledge held by the company. Why not do this for myself?
So here I am, exercising my writing! Please, share your feedback!
Here are some great additional resources:
Why you should write by David Perell
The day you became a better writer by Scott Adams
Writing well by Julian Shapiro
2. A structured goal-setting process and accountability partners will help you achieve your career goals
I worked almost 10 years in consulting firms, with its structured goal setting and performance review processes, so I’m particularly familiar with this. But the goal setting exercise we had at the beginning of the program showed me a different perspective, especially because we were doing it together, outside organizational constraints.
The first thing I enjoyed was setting goals as a group. Putting them on paper, sharing it with other people and hearing other people's goals at the same time can be powerful. It makes your objectives more real and helps you find accountability partners that can help you with ideas, suggestions and follow-ups.
Second, having a structured approach is a great way to surface, document and keep track of your goals. I created a habit of revisiting it weekly, measuring how much progress I made on these goals and reflecting what I needed to adjust, either on the goals or on my routine.
The goal setting process we used was the following:
Define a vision of what you want for yourself. What's most important for you? What's at stake? Having a vision helps us move from negative Emotions (Scared, anxious, Worried, Frustrated) to Positive (Motivated, Inspired, Driven, Curious, Excited). I enjoyed thinking about our "Should Self" (Driven by other expectations, external pressure and fear) vs Ideal Self (Driven by your values and highest aspirations for ourselves) and was surprised and inspired by the clarity some people have on their values and aspirations.
Define specific and measurable goals for the next 6 months. How will you know that you’ve grown? How can other people support you?
Map your obstacles: What might stop you? Brainstorm and acknowledge potential obstacles— including mindsets, excuses, fears, habits, external pressures and scars. Some personal examples: Comparison traps, excuses like "I don't have enough time", focus, imposter syndrome and life scars.
Define your Non-Goals: What will you drop or delegate in order to prioritize what matters? What will you say no to? This is very important. To focus on what matters, you need to deprioritize some things that can suck up your time.
If you have never done this before, try to do it once and let me know how it goes, even if not with a group!
3. Embrace vulnerability and give more than you take to create deeper connections
At ODPM, I learned that I can have fun, feel energized and create serendipity while networking.
Two things were key to make the networking experience better: the embrace of vulnerability and the openness to listen and meet new people, without necessarily having an agenda.
First, shout out to Andrew Yu, Chioma Kalu and Mindy Zhang for setting the tone and carving a path to foster deeper connections between fellows. They were really transparent and open from the beginning and led the community by example.
Here are the 3 things that helped me have a productive networking experience:
Start broad, with fun social events and intro 1-1s: We started the program with a few fun social events and mixers, with icebreakers and good matching algorithms (thanks, Gatheround). That helped us get to know as many people as we could in the beginning. We were also incentivized to have as many 1-1 as we could (considering on our schedules limitations) and almost every one provided a calendly link to make the booking experience easier
1-1s without agenda and being vulnerable: Having no agenda conversations can be very powerful. It leads the chat to unexpected places that you would never get if you’re following a script or trying to achieve a specific outcome. I also think that focusing on identifying how you can help the other person, instead of what help or support you want from them, really works, especially if everyone is the same mindset. Always try to give more than you take.
Deeper groups chat and support with a focus team: During ODPM, you're matched with a group of ~8 people to meet weekly and act as an accountability and support group throughout the program. It became one of my favorite meetings of the week, where we discussed challenging topics raised by one of the participants. Everyone was open, candid and vulnerable, which led to really honest conversations, full of reflections, learnings and takeaways. There's so much we can learn from each other.
These are some of the things that helped me have an enjoyable networking experience with other peers. Would love to hear other perspectives and tips from you!
4. Boost your productivity and thought leadership with note taking and calendar management
I've always struggled with creating new productivity habits. I believe it's valuable to have a "second brain" and get everything out of my head into trusted systems, so I’ve tried it all: from a simple notebook to Notion, goin through Google docs, Trello and Evernote. My struggle was always in how to organize it: it’s important to have a process that helps you define where each type of note should go so you can revisit them later. At some point I usually lost track and consistency.
I learned about Roam Research and bidirectional notes through some fellows (and Jeff Morris Jr.) and started using it. It’s been great. I used it throughout the program to take notes and organize them. I’m also using it for personal work related stuff, like to-dos and meeting minutes. To be honest, I started writing all my notes so it quickly became my single source of truth.
One other thing that also helps me a lot is the Readwise - Roam integration. All tweets I save and all highlights from books or articles are sent automatically to Roam. This really helps me organize my thoughts and consistently revisit them.
There are a lot of great resources talking about Roam already, so I’ll leave a link to some articles and videos if you’re interested in learning more.
Some other great productivity tactics we got from Nitin Julka that I’m trying to apply:
Prioritization: Define 1-3 most important tasks (MIT) for the day, week, quarter or year and say no to everything else. Create big blocks of time to focus on my most important tasks. Align energy levels with tasks (Nitin uses mornings to deep focus on the MITs). Keep 50% open for sudden priorities that come up during the day and have a fixed schedule productivity.
Scope Management: Focus on your priorities. Treat your mind as a private garden.
Responsiveness: Schedule time for email (eg. 11 am and 4 pm). Avoid skimming email because it just creates mental overhead that lingers for hours and prevents you from being productive. Most of the urgencies are exaggerated. Do not multitask and only handle something once.
Commitments & ETAs: Give an ETA on all tasks. If you can’t give an ETA, give an ETA for when you will give an ETA. Then schedule time in your calendar to complete it by ETA
There's a lot more to explore on this topic. I'm working on my system and I’ll explore details in an upcoming post.
5. Solve any type of problem and deal with uncertainty with a structured approach
Problem solving is at the heart of what PMs do. Here are some steps and tricks I learned in the program to improve my personal approach.
The first step to tackle any problem is to classify it. A good framework for this is the Cynefin Framework. A problem can be:
Obvious: The "known knowns". There are rules in place, the situation is stable, and the relationship between cause and effect is clear. In these cases you gather the facts, categorize and respond with a best practice or rule
Complicated: The "known unknowns". The relationship between cause and effect requires analysis, since there are a range of right answers. You need to assess the facts, analyze, and apply the appropriate good operating practice
Complex: The "unknown unknowns". Cause and effect can only be deduced in retrospect, and there are no right answers. Battlefields, markets, ecosystems and corporate cultures are examples of complex systems. Here the answer is to probe with experiments, sense the results and respond accordingly. I loved this quote from a John Cutler talk. "Uncertainty is where the opportunity is". We are making decisions under conditions of uncertainty all the time. We use trust proxies, such as p-value, to create some indication that we are making the right decisions. But in the end it is not science, it's more a game or an art. Uncertainty is uncomfortable and can generate paralysis. We need to try to create some certainty in uncertainty.
Chaotic: Cause and effect are unclear. Events in this domain are "too confusing to wait for a knowledge-based response", according to Patrick Lambe. In this context, we should act (any action) to establish order; sense where stability lies; respond to turn the chaotic into the complex.
For complicated (and even complex) problems, the traditional problem solving process framework is really useful:
Categorize the problem: first determine whether or not this is actually a simple or complex problem
Frame the problem: Add constraints and framing to the problem by using a problem
statement. This is key. If you don't have a clear and shared understanding of what you are actually trying to solve, finding the solution can be very difficult.
Reframe and validate: Pressure test with clarifying questions. Try to reframe the problem and look under different perspectives. Is it really a problem?
Decompose: Break the problem down into mutually exclusive, comprehensively exhaustive sub problems (MECE issue trees are a classic)
Ideate: Come up with possible testable solutions for each of the sub problems
Create testable hypotheses for each possible solution, with as much granularity as possible. A good hypothesis can be clearly refuted or supported by an experiment (validation via experimentation or research)
Test and assess and solve each sub problem individually
Communicate learnings and get buy in by structuring thoughts clearly. The Minto Pyramid is a great framework for this.
There is a lot to unpack here, so I’m planning to write another post with more detail soon, including how McKinsey and other consulting Firms approach problem solving.
6. Get better at product strategy with a clear framework
During the program we discussed different views and approaches for product strategy, but I noticed some consistency among them: the importance of product principles and objectives that are connected to a clear mission.
Here’s my current product strategy framework, refined based after these discussions:
Define a north star: First step is to clearly define and communicate what you're trying to achieve. It needs to be something inspiring, that injects a sense of purpose. I like vision/mission statements for this. Usually a product vision is enough.
This is a good template to help you get started. I see it as a starting point - ideally you should rewrite it in a more compelling form once you have all the pieces consolidated:
For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
One great example of a vision statement is Gitlab. You can also find inspiration in vision statements from your favorite companies
Define your product principles: This is not required and I see a lot of great strategies without it, but through conversations I came to value this as your guiding principles: it will help your team make decisions and prioritize later. They should reflect your long term strategy. Here are some great examples of product principles:
Articulate your strategy: Now you need to describe a more detailed approach of how you're going to achieve your north star. It’s a list of steps that lay out the road you’re taking to achieve your mission. There are a lot of great frameworks to help think about it, like Gib Biddle’s DMH. Here are some great examples of strategy:
Plan the execution: there are different ways of doing that, and I'll explore more in the next topic. Ideally it should be through an outcome-based roadmap that is constantly being reviewed, supported by quarterly OKRs so you have measurable goals to track progress.
All of this should be written in a simple and straightforward way. Ideally you should be able to summarize it in one page. Well-articulated strategies are usually short, memorable and possible to be explained with a framework or metaphor.
Also, Your strategy doesn’t have to be perfect (it almost never is)! Your plan will change as you learn new information, but starting with a strategy helps you make better moves early.
How is this framework different from what you use? I would love to hear feedback and perspectives on this too.
7. Deliver superior products by leveraging quality metrics
Product teams are usually focused on their north star and the metrics that support them to get there, but it’s important to define product quality metrics early in the planning process. Growth, for example, could come at the expense of product quality. It’s important to be aware of this and define what is the standard of "product quality" that you will abide by to ensure that everything you deliver (the overall experience) does not deviate from the larger goals of your business in the long run.
Think of product quality as an overall experience, with multiple things that add up to the experience of the customer. It’s hard to define because it's variable to different users, products and tastes.
Here’s a framework of how to map them:
Define your quality north star. This should be an outcome that you think clearly communicates quality. It should help your team create the right experience for your user:
Is measurable, but more than just a metric
Is one of the highest priority outcomes you’re trying to achieve
Can create healthy tension with another outcome that isn’t quality related
Figure out all the inputs that drive the output. A good input:
Is measurable, but doesn’t have to be a metric
Is proven (or can be proven) to drive the outcome
Is highest leverage, or one of a handful of inputs that will have the biggest impact
After defining inputs, socialized with our teams and got to work to build a product experience that focused on each individual input.
Example from Airbnb Experiences shared by Nickey Skarstad:
Business goal of growth: sell more experiences
Quality goal: 5-star review experiences
In this example, even though the business goal is to sell more experiences, the team identified that it should not come at the expense of offering great experiences to the customers. So they defined a quality goal of increasing the volume of 5-star review experiences, even if it hurts growth in the short term. They identified the inputs as things like experience description, pictures, and searchability. Making these inputs required to users introduced friction to the hosts, but data showed that these detailed experiences were more likely to get a 5-star review. More 5 star reviews mean more quality experiences, which mean users would be happy and the growth would follow in the long term.
More on this topic, including details of the example above, in this great piece by Nickey Skarstad.
8. Outcome-based roadmaps are one of the best tools to plan and communicate business impact
"An outcome is a change in human behavior that drives business results" - Josh Seiden
Once you have your strategy clearly articulated, you need to plan the execution. A product roadmap is where you lay out the plan of how (and in what sequence) you're going to execute your strategy.
But first I like to talk about OKRs (objective and key results). This is a well explored and familiar topic so I won’t go deep here, but OKRs are a great tool to define measurable outcomes and results you’re trying to achieve in a period of time to measure your progress toward the goal. Objectives don’t need to be quarterly, a mistake I see often. You can have an objective tied to your strategy that may take various quarters.
I like to use OKRs to materialize the strategy into more tactical, short term goals. And this would inform what needs to go into the Roadmap.
When I think about a roadmap, the first thing that comes to my mind is a Gannt chart with bars representing features, with start and end dates. I have a small panic attack just by thinking about it (traumatic past experiences).
I see two problems with these type of roadmaps:
The dates usually become commitments
The focus of conversations with stakeholders shifts from the outcomes you're trying to achieve to the features themselves. Your “test and learn” approach may be doomed.
To move away from this you need a very mature group of stakeholders that understand that this is just a visual tool and that things will change when you get into execution. This is very difficult.
That’s why I prefer a simple table with 3 columns (now, next and later). Even better if the content is a list of outcomes instead of of features. Here’s a great piece on outcome-oriented roadmaps by Jason Doherty, including some examples.
One framework shared by Krishna Nandakumar that I also like breaks down your roadmap into 3 categories:
Bets: new things you want to explore but without a clear measure of benefits yet
Outcomes: results you want to achieve that are supported by research and tests
Have to do: legal requirements, technical improvements, refactoring, security, etc.
If you still need ideas and tips on how to transition from timelines to outcome-oriented roadmaps, I also recommend this piece here from Andrea Saez.
To finish this topic (for now), Here’s a great example shared by John Cutler
9. Design a delivery process as you would design a product
Moving to execution, I also have some takeaways around team processes. Usually teams are oriented or forced to use Agile methods, like scrum, “by the book”. This can end up being a burden instead of a tool.
In the end, Process is about improving the chances of a good outcome, like Andrius Baranuskas mentioned in his fireside chat. Process is about raising the floor so that you raise the lowest point. It’s not about being very strict and establishing a ceiling.
Process should try and improve the chances of a good outcome. It’s like a product, so we can approach it like one when designing it.
Key takeaway here is that, in some situations, especially for a new team, implementing a process by the book can be a good starting point to set up a baseline, but you still need to ruthlessly inspect and adapt the process. Stick with what is helpful and remove what is not working.
For teams that are already working together, treat processes like a product. Think about the problem you are trying to solve. And you just need enough process to solve the problem. Don’t overcomplicate it.
To finish it, This observation from John Cutler is also great food for thought. In some digital-first product companies, teams are less influenced by Scrum and build processes from different sources. And there’s no question they are shipping great products and delivering great values to their customers (not to say, most of the time, superior).
10. Don’t limit yourself with labels and focus on developing your product sense
These last two takeaways were shared by Shreyas Doshi and really resonated with me.
The first one is about labels. As a generalist myself, I always hated putting labels on what I'm doing, like "financial services consultant", "data product manager" or "growth product manager". But this is something you see everywhere: just look at job titles anywhere. The takeaway is that it's good to start using labels as you start out or to create rapport and signal something to the industry, but you need to be careful not to believe in them and limit yourself. Almost all PM skills used in a role are transferable to other domains or industries if you are a good one.
This brings me to the second takeaway. Your success as a PM will depend on your product sense (in addition to analytical and execution sense). We can break down product sense in 3 components:
Cognitive empathy
Domain knowledge
Creativity
Product sense is so important because we PMs need to make micro decisions all the time, and we don’t always have data and research to back it up.
You need to identify what is your strength among these 3 components to get exceptional product sense. So if you think domain knowledge is going to be your strength, then of course, rely on it to develop your product sense. This is the only case in which label and specialization really make sense. If your strength is your deep knowledge in cryptocurrencies, for example, and that's your superpower, then it's ok to set yourself as a crypto PM and focus on that.
In my case, I believe it's cognitive empathy. I'm at my best when I'm looking at a problem (or analyzing a set of information) and need to put myself in the user's shoes (what they are feeling, what they are trying to achieve and what is more likely to be their behavior) to get to the best solution. Of course, all 3 are important and you need to have them as well, but knowing your strength is what can get you far.
Conclusion
These are just a few of the takeaways from my experience at ODPM. After all, nothing replaces the feeling of being part of a great and supportive community or the serendipity of great conversations. There was also a lot more on experimentation, leadership, VC, angel investing and more. And honestly, I didn't even watch all the sessions available yet. It was a lot to consume in 8 weeks!
Like I mentioned during the article, I just wrote a brief summary on some of the topics and they'll likely be the focus of deep dive in the future.
If this was helpful to you, please let me know. I would love o hear your feedback. Any questions about the ODPM program? You can find me on Twitter @RafaelDaraya or LinkedIn, Until next time!