SVP of Technical Product Management

Do you want to make important technical decisions across dozens of products that will determine their long term viability? Learn more about this role.

Senior Vice President of Technical Product Management

$ 400k/Year   Flexible   Long-term
Good fit for: Principal Program Manager, Principal Software Engineer, Technical Product Manager

Are you a rockstar lead or chief architect who gets excited by making better software products?

Have you led the design of core products at leading tech companies?

Are you interested in making important technical decisions across dozen of enterprise solutions spanning multiple domains?

Do you want to focus 100% of your attention on the things that matter? Are you interested in designing killer features that differentiate your products and push the limits of contemporary tech?

At Crossover, our SVPs of Technical Product Management make high-impact design decisions that define the very heart of a project. You get to define the critical implementation details and set the boundaries for our others across our TPM and engineering teams. Once that's done, you get to move to another product and do the same again - on up to 20 different product a year.

“The 4-week CTO Bootcamp was challenging but excellent, based on real-world problems. It is a significant investment in Crossover partners, more than I've ever seen in previous companies.”
-Alan C, SVP of Technical Product Management
, we have  full time partners from your country,   Let’s make it !

Crossover recruits and builds world class high performing teams to power the fastest growing portfolio of software products in the world. No other company provides the training and the opportunities to test yourself on the depth and diversity of projects that we do. All roles are location independent so you are guaranteed to work with the best in the world. Challenge yourself. Be part of the change.

We believe that our approach towards Technical Product Management is truly unique. Rather than being tied to specific products for long periods of time, we get involved up-front and make critical, high-impact decisions on the technical architecture and implementation of a product. As part of our team, you will get to work across a wide arrange of domains and technologies. You will have a unique opportunity to grow your existing technical skills and be exposed to the latest technologies.


You will mentor a small team of VPs as they each define the product-market fit and make the most important technical decisions for a particular product. You will control the scope of their decisions and simplify them by defining the design scope and boundaries for each iteration or release. Using your technical expertise you will identify leading open source and SaaS solutions which can reduce the size and complexity of the product codebase.


Each week, you will work across multiple products to:

Simplify technical design specs to ensure optimal product-market fit and that the Important Technical Decisions are focused on the core of the product.

Identify relevant design and integration patterns to standardize product requirements and functionality

Define data structures, object models and algorithms to solve high-value problems

Make decisions that reduce scope in favor of simplicity

Throughout your time with us, you will:
  • Coach and mentor a team of VPs to maintain and improve the quality of level 2 specifications
  • Continually learn and leverage new technologies, patterns, and practices
  • Solve complex, ever-changing problems across an extensive and growing product portfolio
  • Own the creation of precise and straightforward product specifications

A university degree (BS, MS, or Ph.D.) that included an in-depth study of data structures, algorithms, object-oriented programming, computer architecture, and software engineering.

Spent 2+ years working for a commercial software company with the full-time responsibility of writing production code in either Java or C#

Spent 5 or more years making the important architecture and design decisions on software solutions, such as the application of architecture design patterns or significant open source technologies

Have at least 2 years experience as the decision-maker for design decisions involving the use of cloud computing services (such as AWS)

Been the most senior decision-maker regarding technical design decisions for a product at a commercial software company

Timezone Requirements

Our teams are designed to accommodate top talent across a wide range of time zones, however, there are certain hours we require in order to have team-based collaboration or to have customer-facing engagements in the customer's working hours. Candidates should be able to work 8 hours a day while meeting the following constraints Monday-Friday:
  • 2 hours between 9:00AM-11:00AM EST (US "core" hours)
  • 2 additional hours between 8am-8pm EST (US "customer" hours)
  • 4 additional hours in any timezone you wish ("flex" hours)

We believe in continuous growth and strive for constant improvement. As part of our TPM family, you will be exposed to a multitude of new technologies, products and industries on a daily basis, and our comprehensive suite of playbooks will equip you with the foundation to develop and enhance your existing expertise. 

We also provide a unique CTO Remote Camp for all new SVPs of TPM. This full-time, fully-paid training program covers all of the unique aspects within our approach to TPM, including:

  • SME engagement and how to elicit the important information 

  • How to uncover CIV (Challenging, Important or Valuable) Problems in a particular domain/industry

  • How to define Core Functions to address CIV problems and ensure optimal product-market fit

  • How to make the Important Technical Decisions to ensure that:

  • Core architecture decisions are not left to chance

  • Core functionality will be delivered effectively

  • Architecture and development teams are not micro-managed by imposing unnecessary constraints (low-level, unimportant decisions)

Throughout your training, you will get daily feedback to accelerate learning and growth far beyond typical classrooms or training programs.

Our curriculum includes a number of bite-sized training videos where we explain how we design great software. Here’s an example where we show you how to make and validate Important Technical Decisions.

Executive Vice President of Technical Product Management
Hire and Grow Senior Vice Presidents of TPM. Work with industry leaders to create a technology vision.

A good fit for...

Experienced product leaders at larger established SaaS companies who have deep technical experience coupled with strong business acumen. They stay abreast of emerging technologies and visualize how to apply them to create compelling differentiated value.

They are industry luminaries, thought leaders and technology evangelists. They have a blog with a sizeable following, author well-known books and articles in prominent media, or routinely speak and lead workshops at major conferences.

Senior Vice President of Technical Product Management
Hire and Grow Vice Presidents of TPM. Set the technical vision, product strategy and core approach across multiple releases.

A good fit for...

Experienced architects at larger established tech companies who have both deep technical experience and some management experience.

They simplify architectures and make scope decisions.

They are great communicators who see writing technical specs much like writing code. They enjoy developing talent on a team by giving clear and frequent feedback.

Vice President of Technical Product Management
Create L2 specs that make the Important Technical Decisions (ITD) regarding scope, implementation, and acceptance criteria.

A good fit for...

Architects and senior developers who have experience making core technical decisions AND can describe simple solutions to complex problems by using high-level architectural patterns.

They have strong (and well informed) points of view about when to use different technologies, they like to make bold decisions that control scope in order to simplify things, they enjoy designing solutions that minimize the code to be written.

Technical Product Manager
Create L1 specs that define implementation-level technical design and acceptance criteria.

A good fit for...

Technically strong, hands-on senior developers who are interested in a career progression in Technical Product Management.

They care a lot about creating simple, clean software. They have opinions about what makes a great API, database schema, algorithm.

Work Examples
Blockchain Decentralized Apps
Playbook for Using a Blockchain dApp Platform Such as Ethereum
Serverless Architecture
Playbook for Using a Serverless Architecture Such as AWS Lambda

If you’d like to create similar playbooks for your own use, please feel free to use our template.


and Answers

  • What does a good technical product manager look like?

    TPMs should be super-technical and great at connecting the CORE of the software's design decisions to the way that those decisions allow the product to do the "important thing" in the best way possible. They focus on data structures & algorithms, not slick UI/UX. They write their logic/rationale down so that it can be vetted by healthy debate - or at least understood! They engage directly on important topics. They spec important product simplifications ("non-features") as often as they spec the “must-have features.”

  • How would you describe a day of work as an SVP of TPM at Crossover?

    If I had to describe it succinctly, I would say that the main thing an SVP of TPM does each day is to focus on a "thing" that needs a solution. It may be a data structure or an algorithm for a brand new product. It may be how to change an existing codebase to adopt some new technology component that will make the product much better, or retire a bunch of low-value code, or a variety of other problems we are trying to solve. TPMs write down their thinking/logic in the most succinct and precise way possible. They work with other people (global/remote) to ask questions to get peer-feedback, and feedback from their manager.

  • How many products does each role manage? What’s the typical size of each product team?

    We don't limit the number of products that TPMs work on in that way. They generally work on one product at a time, and once finished solving that problem/design, they move onto another product. They may come back to a product too. We want TPMs to have continuous learning. By doing this, our TPMs learn many new technologies, design patterns and architectures, industries, and business models. We have designed our organization and processes so that this works. We like people on the team to contribute work and ideas fluidly, in the same way, that great, high-caliber engineering teams all work on many different parts of the same codebase. As long as they are all of the sufficient skill, collaborative, and have the right review/approval process, so the code isn't a complete mess. It may be slower in the short-term (because of ramp up) but its better in the long-term. Our engineering teams generally follow the "2 Pizza Rule" regarding the size.

  • How are the teams formed within the actual projects and as an SVP of TPM would I have any influence over the selection of the project I'd be working on?

    Our view is that TPMs (and the TPM Org) should not focus on managing or influencing the engineering delivery team. We leave that to engineering management. Our TPMs focus on making the important technical decisions that in aggregate define “how the software should work to deliver customer value” and not on “how the engineering team should work to deliver the software.” An analogy would be the way an Architect's job is to clearly define the crucial decisions regarding the construction of a building but is not part of the building team that the construction company uses to build the building.

  • How do you know what insights are important?

    The important decisions are always there, and they always get made one way or another. The question is whether they are made deliberately and with the gravity they require, or whether you find out how they were made after it is too late. Our process works to identify these decisions early - we invest the necessary time and skill, drive alignment and feedback from all parties, and learn and improve over time. To do this, TPMs must be very technical and able to explain the reasoning for their engineering decisions. TPMs need to see the "big picture" and focus on the important capabilities, not the many minor features. TPMs must be fast learners and great writers and know the difference between controlling what is truly "important" versus micro-managing engineering (which we do not want to do). This is the core of our 30-day CTO Remote Camp process - we, focus on our quality bar, and the goal of our processes.

  • How do you measure success?

    This is a long answer, but the basic idea is that we define actual deliverables for TPMs. These weekly deliverables are quite structured, and we check the quality of the content within those specs. For example, we evaluate how "Important" the content is, how correct the "Technical" content is, and how clear and justified the rationale for the "Decision" is. We call those ITDs, and TPMs get feedback on the quality of their work. So, by measuring the Quality and the Quantity of work, we measure success. In the longer term, we also measure how well those decisions played out in the real world.

  • How does the TPM organization fit within the rest of the organization?

    Our approach to Product Management is heavily technical, and that is because of our belief that the most important thing is mapping the customer problems to a 10x better engineering solution to that problem. We try to simplify and make the core of the product 10x better instead of chasing every little feature that competitors do or developing piles of minor features from the backlog. That said, we also send the core messages to marketing and sales so that they can do their job. Those core messages start with the TPM team.