Product management is about building the right thing, engineering is about building the thing right
…the mantra goes. The more complex technology products become, the more these seemingly different problem spaces converge into a continuous stream of challenges. Dominant companies owe their position to understanding this a long time ago and changing their hiring methods, organisational structures and delivery styles accordingly.
Many industry followers try to catch up the wrong way. They hire bright engineers to boost innovation, but give them little creative freedom, forcing them into the rigid frameworks that govern the rest of the business. Talented people get frustrated and leave or resign themselves to solving minute or immaterial technical challenges, failing to add value and further distancing themselves from the rest of the company. In turn, products either never take off or slowly drift into irrelevance.
Building wide reaching, mission-critical technology products for two decades I have often seen this pattern. At first I took it for granted, thinking that was just how the world worked, so I became part of the problem. But thanks to great mentors and colleagues who taught and helped me see and learn from my own mistakes, I made a checklist for how to avoid it. I refer to the list and refresh it periodically to make sure I do not miss the forest for the trees, as it can often happen when dealing with complex products and organisations.
I hope this helps technology leaders at all levels who face similar challenges. The points below all influence each other, but I enumerated them in causal order.
Take responsibility, paired with authority
If you are a CTO joining an existing company, work with the board, not for the board. The responsibility to deliver goes hand in hand with the authority to challenge the status quo and drive real change. Do not sign up for one without the other.
If the remit presented to you seems prescriptive or strangely narrow, try to understand why. Sometimes that is for a good reason, but it may often shadow an XY problem unwittingly created by the leadership team, who ask you to provide the solution they think the business needs, which is not necessarily the correct one.
Take your time, do your own due diligence. It is always a great sign when the company leadership is comfortable answering tough questions.
If you join a company looking to scale their engineering team, make sure there is a healthy foundation, or at least a mandate to rebuild, otherwise you are just scaling up trouble. Ensure they can survive the tech stack change they asked you to help with. If they want you to improve engineering delivery, make sure to gauge the health of the rest of their product development functions. Do not assume the solution you are invited to implement is the right one. Always ask ‘why’ when presented with the ‘what’.
Hire missionaries, not mercenaries
You have to care about the product, plain and simple. If you do not and still join a company, despite some red flags as described above, you are a mercenary. That is fine, we all have to put food on the table, but do not expect to inspire and motivate your team. If you do not care, why would they? If they do not, no amount of professional coaching and process refinement will lead to anything more than mediocrity.
Hire people who appreciate the business values and mission and the product vision, talented individuals who do not believe in silver bullets and enjoy solving hard problems as part of a team. If the business is not already set up this way, bring in new product managers and team leads with these traits. Part of their remit must be to spread the gospel further into their teams and raise the hiring bar.
If your team’s only incentives are financial or the comfort zone provided by tools they like best (programming languages, frameworks, etc), you are in trouble. Such persons are either inflexible or chase the latest hype wave. They will be the first out of the door as soon as another company pays them a tiny bit more, you adopt technologies they have no wish to learn or conversely when you cannot justify embracing the newest and shiniest right away.
Build empowered, T-shaped and healthy product teams
A team is
- empowered when it sets its own product vision, strategy and priorities to achieve OKRs in line with company goals. Many companies fail to embrace this and persist at driving product ideation from the top. Executives or other high level stakeholders, with input from sales and current or prospecting customers, decide what product is built and why (the loudest stakeholders usually win this debate), but more critically how – the dreaded XY problem again. True innovators – engineers – come into the picture much later and the only contribution they can make is execution. Frustrated, they leave, making room for mercenaries.
- T–shaped when its members share a significant common core of knowledge and skills but specialise in different, but complementary areas (e.g. product management, UX, frontend development, backend development, data engineering, testing). Avoid building teams of disjunct skill sets. They fall into a pattern whereby every person on the team must work on a portion on every item and then another person must work on another portion of the same item and so forth, sequentially. Effectively a Waterfall cycle multiplied by the number of items in the sprint.
- healthy when all its members are on equal footing – different roles, same rank. Some companies have legacy glass ceilings between different disciplines and consider some as servants of others (e.g. QA do the testing, serving engineering; engineering do the execution, serving product; product do the planning, serving sales; sales serve and do the thinking together with the leadership team). This is anathema to collaborative problem solving, alienates innovators and attracts more mercenaries.
Place members of the same team in the same time zone, or better yet in the same office. That creates familiarity, which together with skill and character fosters trust and respect. These two sometimes grow into friendship, but always deliver quality. In teams split across continents everyone invariably takes a hit on their personal life and health, working long hours or taking early morning or late night calls to have some overlap with other teammates. Communication, work relationships and productivity suffer. The more complex the product, the more expensive this layout is.
Invest in product management
If you build a tech product for a tech audience, your product managers must be technically savvy.
Dedicate as much effort to attracting and growing product managers as you do for engineers. They are part of the same team. Good product managers require a rich blend of knowledge – customer, industry/domain, technology, user experience, business and financial, process skills – customer discovery, product discovery, development and optimisation and individual skills – team collaboration, time, stakeholder and community management. Make time to understand their strengths, highlighting gaps or blind spots. Guide and help them develop as you do with engineers.
Involve engineers in hiring product managers and product managers in hiring engineers. That increases their appreciation of each other’s discipline.
Simplify product trial & onboarding
If you build a SaaS/PaaS product, make it available for anyone to try right away, before contacting sales. Keep documentation fresh, accurate and complete.
If your product has an API, expose the real thing, not just a mock. Maintaining a separate low cost instance with rate limits and quotas for functional testing is easy. Use your CI/CD pipeline to keep it fresh. Provide a developer feedback form. This gets you functional validation at the beginning rather at the end of the sales/purchase cycle, which with large customers can take months.
Create a self-service portal for customer signup, usage reporting and payment as early as possible, to free up time for development instead of spending it onboarding customers.
Spread the word (evangelise)
Market research reports show trends with a 12 month delay. If you are happy being an industry follower that is fine, but if you aim to be a leader and also learn how customers use or would rather use your product, there is no substitute to meeting them face to face.
You built a team of missionaries, all of whom are proud of their work. They are the most qualified people to tell the story of their product at meetups, conferences, hackathons and other relevant industry events.
What is a relevant event? Suppose you are building the next Stripe. Instead of attending payments industry trade shows where you compete for attention against tens or hundreds of other companies, go to tech events where other engineers go. Many of them work for startup companies which may already be looking for a payments solution. You directly connect your product to its target audience – other engineers. This helps your demand and lead generation and gets talented people interested in joining your company.
Keep a lean engineering blog of how you solve tough challenges. It inherently plugs your product. There is no shame in that if the content is good.
Collect feedback (advocate)
Allocate budget for developer advocates. They are your customer relations. They gather feedback and relay it to the product team, maintain and improve developer tooling and documentation, give product demos, set up POCs, develop and nurture an open source community around the product. Offer the role to existing team members before hiring externally (but backfill them), as they already have a rapport with the team and understand the product intimately, having helped build it.
This approach creates a continuous feedback stream that shapes the product in near-real time. You are Agile across the entire product development lifecycle, not just the engineering portion. This puts you well ahead of companies that build roadmaps in quarterly or yearly cycles using unproven but more important unprovable assumptions of both revenue and development time and cost.
Avoid or limit duplicate and bespoke work
Encourage collaboration between product managers. They may discover common functionality across their products that can be built into a generic service, avoiding effort duplication and siloing.
If you run a startup company, think hard before building a product for just one customer, no matter how attractive that revenue is. It will be the first red flag raised to a potential investor during tech due diligence.
Avoid building intrusive and non-reusable features for demanding customers into your core platform (e.g. those that might save them a week of integration work but subsequently create days or weeks of yearly maintenance work for you). Build them as shims instead, using API gateways, integration platforms, lambda functions, etc. That keeps such features easier to maintain and refactor as your platform evolves.
Give your customers strong incentives to move away from the shims, either financial or functional (e.g. give them access to great new features only if they migrate to the latest generic platform API).
Closing note
A lot has been written in the past two decades about why technology products succeed or fail and what organisational structures best support them, but there are much older success stories we can learn from.
One of my favourite books about aerospace engineering – Skunk Works: A Personal Memoir of My Years at Lockheed by Ben R. Rich – offers brilliant insight into what gave the United States the edge over the USSR during the Cold War: a bottom-up innovation model based on cross-functional teams of highly motivated people united in vision and purpose, working closely and transparently in quick iterations, using clear and effective communication. The book shows how difficult it was to access funding and control supply chains to support a high secret operation. But more importantly how reverting to a top-down, design-by-committee model at the end of the war resulted in less impressive outcomes at much higher cost.
The Skunk Works model is what dominant technology companies use and others try to replicate. But just like in the book, for it to actually work, will must come from the top.
***
Following two sell out conferences in 2023, we’re proud to announce the launch of CTO Craft Con: London 2024, where we’ll relocate to the prestigious QEII venue, driven by the ever-increasing demand and growing number of attendees.
Pre-registration is now open! You can sign up here to be the first in the know when Super Early Bird tickets go on sale.
If you’re not a member of the free CTO Craft Community, what are you waiting for? With over 10,000 global technology leader members, you’ll get exclusive access to Slack channels, conference insights and updates and other valuable content.
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.