My Journey in Product and Technology: Part 1

The last time I sat down to write a blog post was in November 2014, so bear with me as I recalibrate my bearings.

In the past years, I transitioned from a hardcore engineer to a leadership role, then to a tech founder and entrepreneur. After my startup got acquired, I now lead Technology and Product at RightShip, a maritime tech company. This journey taught me a lot, and I feel compelled to share what I have learned along the way. Building tech products is easy; building useful tech products is hard. It’s a learning experience we all need to go through, but I hope this series of posts will be of some help to you.

In this series, I will focus less on engineering — which is what I used to blog about — and more on product development. I want to share my learnings, as I think they are crucial. Building tech products is fascinating; it is, to a certain extent, an art. But make no mistake, no one is born ready to build products. It is a skill that one needs to educate themselves in. Underestimate this, and you may do well, but not great. Experience by itself is very powerful, but mix it with knowledge and openness to new techniques, and you have something great.

Building Software vs. Building Tech Products

As an engineer passionate about writing code and leveraging new technologies, it’s easy to focus on how we build things — that’s the fun part. But how is it used by the end customer? Did I solve a problem, or just build something because I could? Initially, my career focused on the ‘how’ without considering the ‘why.’

Things changed when I realized asking ‘why’ made my software more impactful than any elegant code. It’s not about how fast I can build features; more features often lead to more complexity. Understanding the ‘why’ from the customer’s perspective is better than just asking what they want, as it helps focus on building context, not jumping into solutions.

If you are reading this, you’ve likely heard it before: always focus on the problems, not the solutions. The solution comes after. This is challenging, especially in organizations where business stakeholders, like sales teams or executives, traditionally own the technology and push problems to the tech team. If your tech team works on a list of requirements from business stakeholders, you’re in an IT company, not a product company.

Transforming tech teams into product teams is not easy; it requires making many decisions, scouting for problems through continuous discovery, and being comfortable with fast, graceful failures to ensure each failure still has ROI.

In the next section, I’ll share some of my lessons learned so we can grow together.

Where Should I Start?

I would say, a good starting point would be the following 3 things

• Some Structure — who does what
• Cadence, Ceremonies, and artifacts
• Product Strategy and Vision

Some Structure — who does what?

A product team requires a Product Manager, a Product Designer and an Engineering team. Do you need a separate individual for each? Not really, in the smallest of teams as such 1 person can be all 3. However many times you will find that these roles are taken by different individuals. What is CRITICAL is that they work as 1 team. Affinity matters, having an engineering team switching from one PM to another does not work. The team needs to build context, they need to own what they build so changing the team is really something you should avoid at all costs.

Product Trio: Teresa Torres in her book Continuous Discovery Habits, refers to the Product Manager, Product Designer and Tech Lead as the Product Trio. I will adopt this term in the rest of the article.

The Product Manager (PM) is the leader of the group, not in an HR sense, but as the owner of the problem we are solving for the customer. The PM is ultimately responsible for ensuring that the solution we build addresses that problem, making them the ‘Problem Owner’. Finding and understanding the ‘WHY’ is critical for the PM. This understanding must be used continuously throughout the building process to ensure we are truly addressing the problem and not just implementing ideas because they seem cool.

Additionally, the Product Manager must have a good commercial sense of why solving this problem for the customers will generate commercial success for the company, ‘Commercial Owner’. This aspect can be challenging for many, as it requires having the right elements in place. Hopefully, in this series, we will provide insights on how to address this effectively.

The Product Designer is responsible for understanding the ‘Why’ so they can develop solution options that solve the customer’s problem. The Product Designer owns the ‘HOW’. One might think product designers are easy to find, but do not underestimate this role. We are not looking for a designer who can only create visuals; we want a designer who can develop solutions — a problem solver more than an artist.

A product designer should be agile, capable of creating multiple prototypes to validate solution options with customers. It’s crucial to be careful with this role; having only a visual designer can lead to issues. If the PM is telling the designer what to do, then there is a problem. Either the PM doesn’t understand the role of a Product Designer, or the designer is not fulfilling the role of a true Product Designer.

The Engineering Team should consist of a small group of engineers, ideally around 5–7 people, but it can be smaller depending on the project’s size. Going larger than 5–7 engineers is not advisable, as smaller teams tend to be more agile. The team needs to be cross-functional and own everything they build from end to end. While this may seem challenging, failing to do so often results in problems and blame games.

In a team of 5, it might not make sense for all engineers to attend every product ceremony, but it’s crucial not to exclude the tech team entirely from these meetings. A Tech Lead should be part of the Product Trio and act as the voice of the tech team. This is vital and can make or break the product team.

The product operating model requires that the PM does not dictate tasks to the team, if you have this then you know you need change. Solutions should be built collaboratively by the PM, Designer, and Tech Lead as one unit. There are many best practices for product engineering teams, and I will delve into these in future articles. For now, I want to emphasize one critical practice: short release cycles.

If your cycle time exceeds two weeks, this needs to change immediately. This doesn’t mean releasing to customers every two weeks, but the team should push new code to production regularly. If the code isn’t ready for customers, use feature flagging or other techniques to switch it off. Not maintaining such a cycle often results in the team spending more time on regression testing and resolving merging issues rather than focusing on solving the problems the product team aims to address.

Product Operations (Product Ops) is a new and emerging practice focused on ensuring the product team is well-supported. Product Ops do not own a proposition but act as enablers, providing market data, coordinating ceremonies, managing customer engagement, overseeing necessary tools and artifacts, and assisting with go-to-market strategies and cross-departmental coordination, such as with marketing. While the Product Manager remains the owner and holds responsibility, Product Ops support larger teams, enabling the PM to focus on strategic priorities. I’ll discuss in a future article how I’ve seen this approach work effectively.

Cadence, Ceremonies and Artifacts

I’m a big fan of SCRUM. As a methodology, SCRUM provides structure to the chaos, offering clear guidance on what should be done. Product development is still an evolving space, and while there’s no single right way, there are certainly wrong ways. I can share my perspective, but I highly recommend reading Marty Cagan’s books for deeper insights.

Without cadence, ceremonies, and artifacts, you don’t have a cohesive product practice; you have individuals doing their own thing, leading to inconsistencies and making it very hard to scale.

I like to split this into two cadences to run an effective product team — Product Execution and Continuous Discovery.

Product Execution

Below, I will outline the five stages I’ve used for product execution. More detailed explanations for each stage will be provided in future articles. Important Note — Product Execution has a prerequisite: you must have a Product Strategy with an outcome roadmap per proposition. Product execution follows a cadence where you execute the roadmap items. Without a product roadmap, your team will be confused and lost. Imagine yourself in the middle of nowhere without a map — that’s how product teams can feel if Product Leadership does not provide a product strategy. Product execution is a process in which the product team validates opportunities from the roadmap.

Opportunity Discovery — ‘Understand WHY’
Led mainly by the PM, the purpose of this phase is to validate a problem statement and ensure we understand why it is important to solve this problem. You should interview 5 customers to gain such insights. Why 5 customers? This is a recommendation from Design Sprint methodology, which I have found very effective. During opportunity discovery, we also need to assess the magnitude of the problem. Opportunity sizing happens in this phase as well. Additionally, we must gauge the willingness-to-pay from the interviews, so choose your interview questions wisely.
Artifacts: As-is user journey map, tagged interview recordings, Slides with opportunity size and clear problem statement
Timeframe: Aim for 1 week, no more. It’s challenging, but achievable with the right support.

Solution Discovery — ‘Learning HOW’
The product trio — consisting of the PM, Product Designer, and Tech Lead — starts creating solution options that address the customer problem identified in the Opportunity Discovery phase. The objective of this phase is to prove that your solution will address the problem. Once we have solution options, we will test these against another 5 customers. It’s important to assess willingness-to-use during these interviews, as sometimes this is overlooked, and even perfectly good solutions are not adopted.
We also need to figure out what the solution would cost to build. By the end of this phase, we will be able to present a clear ROI for building the solution, as we have the opportunity size from Opportunity Discovery and now know the cost to build. From a commercial standpoint, this allows us to make an informed decision to build or not to build. This decision is crucial. If you decide not to build, be happy — without this model, you might have gone ahead and built something that would waste a lot of time and money, only to scrap it later.
Some of the best techniques here are from the Design Sprint by Jake Knapp (check out the book section below).
Artifacts: Low-fi prototype, to-be user journey, cost to build, investment deck showing ROI.
Timeframe: Again, Aim for 1 week.

Planning — ‘Measure Twice, Cut Once’
In this phase, the product trio will start planning based on the discoveries they have made. The PM will create User Stories, the designer will develop high-fidelity designs, and the tech lead will outline a target architecture. Together, they prepare everything needed for delivery to kick off. The PM will use story mapping to prioritize the stories and structure the releases. Additionally, the PM should work with the commercial team to develop a commercial plan / GTM that can realize the opportunity size identified in the Opportunity Discovery phase.
It’s critical that the rest of the organization (outside the product team) is also involved in an inception meeting. In this meeting, support, marketing, commercial, and other departments are invited to learn what the product team will be working on. This ensures that all departments can contribute and start planning their support for the product’s go-to-market strategy.
Artifacts: Prioritized backlog, High-fidelity designs, Target architecture, High-level release and commercial plan.
Timeframe: 1 week

Delivery — ‘Let’s Get Some Action’
In this phase, the full product team engages in delivering the backlog items according to the story map releases. I won’t delve into the details of the delivery process in this article, as it deserves a blog post of its own. However, I will emphasize that sprints should be as short as possible, ideally not exceeding two weeks.
Timeframe: 2 week (can be multiple sprints)

Evaluation — ‘Inspect and Adapt’
Yes, evaluation should be a phase in your product process, as it is often overlooked. The purpose of having a set of ceremonies is to ensure that, even when we get busy, we don’t neglect essential product needs. If you do not measure post-launch, you are making a big mistake. The whole point of launching early is to get feedback and improve. The product team learns a great deal from this phase. I will cover this in more detail in a future article, as this topic is very extensive.
Timeframe: N/A depends on the product, many times on-going.

Other Artifacts: Besides the artifacts mentioned in the above Product Execution, there are other artifacts such as the Product Team Diary, qualitative research repository, and outcome roadmaps which are all critical to the success of the product team; do not underestimate their value. Artifacts allow product teams to get better as time goes by and allow such teams to scale. Some of these artifacts, I will cover in a future article as the post is getting much longer than I intended 😊

Continuous Discovery

Product execution follows a cadence designed for your product team to deliver on the roadmap items. This framework enables work on known outcomes. However, it’s equally important to have a cadence for discovering new outcomes, necessitating a habit for Continuous Discovery. Allocating 20–30% of the product team’s time to Continuous Discovery, is essential (with the remaining 80% on product execution). This separate cadence ensures that discovery remains a priority, integrating it into your culture and way of working.

Continuous Discovery involves establishing habits for your team. For example, each PM might conduct one customer interview per week, the Product Trio could spend two hours evaluating analytics with Product Marketing, and a bi-weekly commercial review could be held with the commercial team to gather frontline insights. At my company for example, we’ve also implemented an idea submission portal, allowing everyone to submit new ideas for the product team to triage.

There are many ways to approach Continuous Discovery, but the starting point is allocating time for it. Your product teams will always be busy, so setting a rule for Continuous Discovery ensures it gets done. Continuous Discovery is crucial as it challenges your roadmaps, helps you stay attuned to market trends, deepens your understanding of customers, and fosters closer collaboration across the organization to uncover unknown opportunities.

Product Strategy and Vision

As suggested in the previous section, a product team without a product strategy is a failure on the part of product leadership. It’s like putting someone in the middle of nowhere and expecting them to find their own path. Some might succeed, but many will not. You’ll need superhero PMs, and such talent is rare. Instead, if product leadership sets a strong product strategy with a clear vision for each product team, the chances of success drastically improve.

In the product process, we do not want to manage top-down; we aim to “lead with context instead of control.” This context comes in the form of a product strategy. The Chief Product Officer (CPO) or Head of Product should outline the product proposition and a clear vision for each product team. The product strategy chapters will show how to achieve this vision. Under each proposition, there should be a roadmap that orders the outcomes based on these strategy chapters. An outcome roadmap focuses on goals and key results, rather than detailing the development of specific features.

Outcome roadmaps differ from feature roadmaps, as they contain items to be validated, not to be built. We need to validate problems and potential solutions through the product process. The roadmap is a crucial artifact because, during execution, new items will arise and it helps you understand each opportunity relative to others, enabling you to logically sequence new opportunities in your timeline.

The outcome roadmap is not set in stone. At my company, we update it monthly based on what we learn in continuous discovery. The roadmap helps us understand what we initially planned to work on and helps us prioritize which opportunities to validate first.

We will delve deeper into product strategy and roadmaps in a future article. However, if you are currently running a product team without a clear strategy or if you ask your product manager to create their own roadmap without much strategic guidance, it’s time to reconsider. The PM must own the roadmap, but the strategy and vision must be set by the product leadership.

Conclusion

In this series, we will explore these concepts in more detail. I’ll share my views on how a tech product team should function and interact with the rest of the organization. We’ll discuss the importance of having a clear vision and roadmap to guide product teams and ensure they feel confident in their direction. I hope this introductory article was helpful.

Below are some books that helped me learn a lot of this:

• “TRANSFORMED: Moving to the Product Operating Model” by Marty Cagan: This is one of my favorite books as it immediately resonated with my situation and helped me understand that my thinking was on the right path. It provided answers to many of my questions.
• “INSPIRED: How to Create Tech Products Customers Love” by Marty Cagan: Another great book, it was an eye-opener and confirmed many of my feelings and thoughts.
• “Build: An Unorthodox Guide to Making Things Worth Making”: A must-read, especially if you are an entrepreneur. This book offers invaluable insights and guidance and will likely become your favorite.
• “Design Sprint” by Jake Knapp: This book is essential for learning how to quickly validate ideas and solve problems efficiently through a structured, collaborative process.
• “Continuous Discovery Habits” by Teresa Torres: This book provides practical guidance on how to incorporate continuous discovery into your product development process, ensuring you stay aligned with customer needs and market trends.