The Formative Years
My passion for computers began as a preteen, when my father brought home an Apple IIc. I was fascinated by both its capabilities and its sleek design. I started teaching myself to program in BASIC and soon moved on to Pascal. The first program I built that felt genuinely useful was a mathematical function plotter. I used it, much to the frustration of my math teacher, to let the Apple plot the graph of a function instead of drawing it by hand for homework. It was a small act of teenage efficiency, but it captured something that would stay with me: the instinct to use software to simplify difficult or repetitive work.
That early fascination made choosing a college major easy. I enrolled at the University of Karlsruhe to study computer science. Alongside my interest in programming, I became fascinated by biological brains and how intelligence emerges from networks of relatively simple components. That led me to focus my studies on machine learning, particularly artificial neural networks. I wrote my master’s thesis while spending a year at UC Berkeley, researching a self-organizing model of the honey bee’s antennal lobes and their remarkable ability to distinguish among thousands of odors. For a while, I considered pursuing a PhD and staying in academia. In the end, I chose a path that combined the two things that had drawn me in from the beginning: building software and applying machine learning to problems beyond the classroom.
Neurotec
I began my career at Neurotec in Germany. My first role was as a software developer on a new Data Mining Workbench product, and it felt like exactly the kind of work I had hoped to do. I was fascinated by machine learning and artificial neural networks, not as abstract academic concepts, but as tools that could be applied to real business problems.
That early experience gave me a lesson that has stayed with me throughout my career: technology by itself is not a product strategy. It is easy, especially early in a technical career, to become enamored with sophisticated approaches because they are intellectually interesting. But elegant technology is not the same thing as a useful product. A neural network may be exciting, but if a simpler expert system or a set of decision rules solves the customer’s problem more effectively, the simpler answer is often the better product decision. Neurotec taught me the danger of building software without a deep understanding of actual user needs. It also gave me my first real appreciation for the difference between technical possibility and product relevance. That distinction became a foundation of how I think about product management.
Siebel Systems
After graduating from MIT Sloan, I joined Siebel Systems as a product manager. At that point in my career, Siebel was the right place to learn the craft of product management. Unlike many technology companies in Silicon Valley, Siebel was not engineering-driven. It had a strong product management culture and treated the role as central to the company’s success. I was responsible for advanced analytics products, including data mining and real-time decisioning. One of the most important products I worked on was Siebel Real-Time Decisions, which helped organizations improve the value of inbound customer interactions by combining predictive analytics with dynamic business and treatment rules. It was ahead of its time. Long before the current AI boom, RTD learned from each customer interaction and updated its predictive models in real time, without requiring manual offline model building or retraining. The product was an instant commercial success, generating over $5M in license revenue alone in its first year.
Siebel taught me that a product is much more than the software that ships. A product manager is accountable for the full ecosystem around the product: positioning, sales readiness, support, partnerships, customer adoption, and long-term direction. It was also where I learned that product management requires leading without authority. The product manager sits at the center of many functions but rarely controls them directly. It was a demanding environment, and in many ways a defining one. I learned that the “buck stops here” with product management. When things go wrong, the product manager is often the one blamed. When things go well, the credit is usually more distributed. That is simply part of the job. Siebel also taught me the importance of discipline. Large customers can create pressure for special-purpose work, especially when the commercial stakes are high. But customer specials can pull a product away from its core vision. The hard part of product management is not collecting more requests. It is deciding what matters, what fits the product direction, and what should be left behind.
Birst
After Siebel was acquired by Oracle, my former manager approached me about joining the company he had started. He had left Siebel about a year earlier and convinced me to become Birst’s first product management hire. What drew me to Birst was the mission: bringing business intelligence and analytics to the cloud. Salesforce had shown what SaaS could do for CRM. Birst was pursuing a similar transformation for BI and analytics. Joining at that stage gave me a very different kind of product education. At Siebel, I learned product management inside a company with established systems and expectations. At Birst, I helped build many of those systems from the ground up. The work required not just product judgment, but organizational design: defining roles, creating processes, and establishing ways for product, engineering, sales, support, and customers to work together as the company scaled. Birst experienced triple-digit revenue growth over multiple years and positioned itself as a “Challenger” in Gartner Magic Quadrant for Analytics platforms.
One lesson from Birst has stayed especially clear: roadmaps should not be lists of features. They should express the problems the company has chosen to solve and the opportunities it has chosen to pursue. A feature list can create activity without direction. A problem-oriented roadmap creates focus. Birst also expanded how I thought about design. Design is not just the user interface, the visual treatment, or even usability. It is the customer’s entire experience: how the product is sold, how customers are onboarded, how they get support, and how they grow with the product over time. As a startup matures, the product development process has to keep pace. The way a startup generates ideas, evaluates requests, handles defects, and incorporates customer feedback changes with scale. Early on, when quantitative usage data may be limited, qualitative feedback from customers and users can be invaluable. But as the organization grows, informal processes no longer work. The challenge is to create enough structure to scale without losing the sense of urgency that made the startup work in the first place.
SAP
One of the reasons I joined SAP after more than six years at Birst was personal: I wanted to take my family back to my home country, Germany, for a couple of years. I accepted a position at SAP’s headquarters in Walldorf. Between accepting the offer and starting the role, SAP went through a reorganization, and the position I had accepted in Walldorf was effectively moved to Vancouver. I ultimately joined on the condition that I work out of SAP Labs in Palo Alto. At SAP, I was responsible for SAP’s location intelligence offering and worked closely with technology and solution partners, including Esri. I led the strategy to develop native capabilities rather than rely on third parties for what I believed was a core capability. I also worked on M&A strategy for the SAP Analytics business, including an acquisition plan to integrate an infographics software provider with SAP Analytics Cloud and an assessment of Paxata for self-service data preparation.
SAP reinforced one of the most important disciplines in product leadership: knowing what not to do. Large companies have many stakeholders, many valid requests, and many plausible directions. Without the ability to say no, product strategy becomes diluted. It also sharpened my view on communication. Customers should not be left guessing about product direction. Internally and externally, decisions and plans need to be communicated clearly and proactively. Silence creates confusion, and confusion erodes trust. SAP also helped me clarify what it means for a product to be ready. Readiness is not just feature completeness. A product is ready when the company can actually run a business on it. It must be scalable and performant enough for real use. It needs a strong regression test suite. It must be instrumented so the team can understand adoption and behavior. It has to be maintainable. It should be consistent with the company’s mission and brand promise. Most importantly, it must be something the team can release with confidence.
MicroStrategy
I had long admired MicroStrategy’s product. Architecturally and functionally, I considered it one of the strongest business intelligence platforms in the on-premise era. When I was offered the opportunity to lead product management, I could not say no. The role also brought my family closer to Germany, which allowed us to spend more time with my relatives. At MicroStrategy, I helped lead the company’s transition from an on-premise software vendor to a provider of business intelligence as a cloud service. That transition was not just a technology shift. It required changes in product thinking, operating model, customer expectations, and organizational behavior.
MicroStrategy deepened my appreciation for the role of culture and leadership in product execution. Product teams need to understand the product vision, the business objectives, and how progress will be measured. Without that clarity, teams may stay busy but not necessarily move the business forward. It also reinforced my belief that leaders should manage toward outcomes, not tasks. General Patton’s advice captures it well: “Don't tell people how to do things, tell them what to do and let them surprise you with their results.” Strong product and engineering teams need clear goals, context, and measures of success. They should then have the room to determine how best to get there. I also came to believe that product and engineering organizations should be built around major problems, opportunities, or themes rather than around the technical architecture. Organizing purely by technology stack can make product management harder because customers do not experience the product that way. Customers experience outcomes, workflows, and value.
MicroStrategy furthermore gave me a clearer appreciation of how product managers mature. Early in their careers, many product managers think in terms of features. With experience, they begin to think in terms of market problems and opportunities. At a more advanced stage, they can form a coherent product strategy and vision. The strongest product leaders go one level further: they understand buyer psychology, stakeholder motivations, and the communication needed to influence complex organizations. That is the difference between passively following what engineering builds and actively shaping where the product needs to go.
Oracle
At Oracle, I served as Group Vice President of Product Management and built a cloud analytics and AI product line from the ground up into a successful business. My first priority was to build the leadership team. That meant hiring strong product leaders with deep expertise across ERP, SCM, HCM, and CX. I owned the end-to-end strategy for data, analytics, and AI SaaS products, purpose-built for Oracle’s SaaS applications. The role required close alignment with engineering, go-to-market teams, and a global product organization. It also required building not just products, but the operating rhythm and leadership system needed to scale them. The market reception of the new product line was extremely positive. When I left Oracle, it was generating several hundred $ million in ARR.
Oracle brought together many of the lessons I had learned earlier in my career. Product managers need to describe features in terms of the problem they solve and the outcome they are meant to create. They need to engage in iterative product discovery and test their assumptions. Most product ideas do not deliver the expected value, which makes disciplined discovery and prioritization essential. At the leadership level, I came to see the head of product role as a combination of vision, judgment, and organizational design. The job is not simply to approve roadmaps. It is to create the conditions under which the organization can consistently make good product decisions. One of the most important parts of that work is deciding what not to do. If a team does a few things exceptionally well, many missing or delayed features matter less than people think. Focus creates leverage. Sprawl creates drag.
Oracle also shaped my approach to building and leading teams. Some of the best product management talent can come from adjacent functions, such as professional services and engineering, especially when those individuals have strong customer understanding and the ability to think in terms of outcomes. But hiring and promotion require discipline. Tenure alone is not a justification for advancement. A promotion signals to peers what the organization values, and leaders need to be conscious of that signal. I also learned to treat performance management as an ongoing leadership responsibility rather than an annual process. Feedback should focus on desired future behavior, not just past performance. Stakeholders and peers should inform it, it should be reinforced through regular one-on-ones, and it should be balanced with visible recognition for strong performance and behavior throughout the year. At the same time, empowerment cannot be reduced to softness. Leaders need to set clear goals and expectations, make decisive calls when needed, and insist that once a decision is made, the team stands behind it. A healthy product organization gives people room to disagree before a decision, but it cannot function if disagreement continues after the decision. I also became convinced that brilliant jerks are not worth the cost. A high-integrity, collaborative performer is often far more valuable to the organization than a renegade high performer who damages trust and morale.
Finally, Oracle reinforced the importance of execution rhythm. A product organization at scale needs regular operating mechanisms: daily product management stand-ups, weekly execution reviews with engineering and release management, and quarterly or semiannual strategy sessions with senior leaders. Those forums create visibility into progress, risks, misses, surprises, and the goals ahead. They keep strategy connected to execution. And they keep a large organization from drifting.