Technical Product Leadership from Head to Toe
By Robert Elves, Senior Director of Product, Tasktop
As Dr. Mik Kersten emphasizes in his book Project to Product, the strategic re-alignment of the business and IT around software products is the key to any impactful digital transformation. This shift, however, is not purely technological — it’s driven by people too.
This trend is reflected by the host of new roles that are beginning to emerge to support this transition. One such role I’m intimately familiar with is that of ‘Product Value Stream Lead’, a role that enables me to leverage my business, product and technical experience to help guide the product towards success.
Because my background is software engineering, and I lead one of our products in the early stages of its lifecycle, the technical aspects of my involvement are still key. I influence strategic technical decisions and investments at the highest level and consider my role to be technical product leadership.
As such, I’d like to share key tips on what it takes to be a technical product leader, which in my experience requires investing your whole body.
Eyes
A vision of what the future looks like is essential. I’m not just talking data-driven forecasting — you need both human creativity and insight too. You must have an eye for the strengths of new technology and how it can address a business/customer problem.
Fact: If your team is not placing strategic bets on technology, at worst you die, at best you are playing catch up while losing market share to those with clearer vision and higher risk tolerance. And if your team is placing strategic bets that are not informed by product vision, you’re moving quickly in the wrong direction.
A vision for how your product will function in the future is essential. James Clear said it best, “When most people envision the future, they project the current form forward rather than projecting the function forward and abandoning the form.” The degree of architectural independence among the components of your product will determine how easily (or not) you can capitalize on future opportunities. Use your first principles thinking to break down what exists today into fundamental value-adding components. How can those be re-configured to improve the product, to increase your addressable market, to solve an even bigger (perhaps more lucrative) problem?
Ears
If you’re not listening to what is happening on the front lines, at the interface between your company and customer, you won’t have the necessary information to steer the product toward a better market fit. Sales, pre-sales, customer success and support people are your ears — and thus an extension of the product development team.
Listen to your customers first hand. For example, use product- or feature-level net promoter scores (NPS) and surveys to listen to your users (or prospects). Even better, get out of the office and meet them face-to-face. I’ve benefited from listening to customer advisory board members, meeting customers on site, and receiving “reverse demos” where customers demonstrated back to me how they work and use the product.
Brain
The brain is where the synthesis happens. Let the creativity flow! You need downtime for the brain to synthesize all that you have been seeing and hearing from your team, customers and stakeholders. The mind needs to wander in order to make those creative connections. Take time to do whatever sparks your creativity. Pull a design team together for a collaborative session once everybody has had time to digest the problem. All ideas are put on the table, no judgment. While this brainstorming may not solve the issue straightway, a shortlist of viable design alternatives will likely emerge.
Mouth
Product leadership (technical or otherwise) is all about communication:
Communicate upwards in your organization with thematic roadmaps and release plans. What’s going to move the needle for the customer and the business? What’s going to meet a new customer need, increase revenue, improve customer retention or reduce time to market?
Communicate downwards to your team(s) with as many specifics as is practical. Roadmaps are great, but if they are only presented to the executive leadership team, how are the boots on the ground going to make the best tactical decisions? Do the teams involved truly understand the short-term and longer-term product vision? Do they have a technical roadmap that interleaves with that product vision? This need not be cemented from day one, but have they thought it through? Product development must remain agile while not painting themselves into a corner, both from a UX and information architecture standpoint and from a technical architecture standpoint.
Communicate outwards to your customers, it’s the best way to gauge if your product is meeting their needs, or if a new product or feature your team is planning will hit the mark.
Stomach
You can’t de-risk everything. At some point, you must make a decision, and as a product leader, your job is ensuring critical decisions are being made. You’ve got a vision for the future of the product that aligns with the business priorities. You’ve listened to your customer needs and worked with engineering to ensure the right technical trade-offs are being made today with an eye for the long-term product vision. You’ve spoken with technical sales and customer success representatives. You’ve poured over all the user telemetry, net promoter scores and survey responses. Your design team has come up with viable alternatives. It is never enough to guarantee success. Your job is to make good decisions when faced with incomplete information. Digest, then go with your gut!
Heart
Product leadership is not for the faint of heart. Vision without passion and grit is not going to get you through the fire when ensuring successful delivery of a new product or feature to market. Challenges you may face on the journey include (but are not limited to):
- Product Design — You have a team of skilled experts, use them to help navigate
- Staffing — Team composition and size have a major impact on velocity and success
- Legal — Consider end user license agreements, master services agreements, service level agreements and open source licensing
- Security — Invest here wisely, lest you become the next Equifax
- Operations — SaaS products have a lot of upsides, but there are operational costs you must keep in check to ensure they scale to profitability
Hands
Get ’em dirty! Build that spreadsheet! Munge that data! The goal is to familiarize yourself deeply with the domain/problems/features/options/decisions/prices/customers — you name it. If you don’t consider yourself a technical product leader, learn to code or at least understand the principles. This will go a long way to fostering empathy for what the engineers do and give you a footing for when the conversation turns technical. Making time to invest in your domain understanding will pay back in terms of a better feature, a better product and ultimately, happy customers.
Nose
When something smells bad, you address it head on. That bad smell is something that will derail your mission or otherwise negatively affect your ability to capitalize on opportunities in the future. Here are a few bad smells I’ve encountered:
- Not invented here syndrome (otherwise known as reinventing the wheel): This is the practice of building something from scratch that is readily available either in open source or commercially. Don’t reinvent another wheel. And by that I mean any software component that solves a specific problem and is commonly (often freely) available and battle-tested. Focus on the unique value-add that only your team/company can bring to your customers. The consequences of this bad smell will lead to longer time to market due to up-front time wasted implementing what already exists. And later, fewer engineering cycles will be available for product innovation due to time wasted maintaining your snowflake implementation of an already commoditized component.
- Failure to elicit engineering input: Engineers have the most information about how the product/solution works, and the extent to which things are and aren’t technologically possible. Without grounded input, designs can reach too far (or not far enough!) in numerous ways. Better to integrate the facts into the design early vs. reworking after erroneous hi-fi wireframes have been freshly minted.
- Shifting the burden to the intervenor: You’ve got a rock star developer on the team — talented, experienced and responsible. She takes on the hard problems, the hard decisions and, unfortunately, all the responsibility. This rock star is a tremendous asset but managed incorrectly will undermine the competence and autonomy of other team members. In systems-thinking, this is known as shifting the burden to the intervenor (for background see Peter Senge’s “The Fifth Discipline”). Here, the rock star has become (knowingly or not) the intervenor, intervening on behalf of all other team members. This results in diffusion and deferral of responsibility (and accountability) among other team members to the rock star.
Feet
A swan on the surface of a lake may look graceful and poised, but under the water those feet are moving! As a technical product leader, you are a people person. You can communicate at all levels of the organization and navigate some difficult corners with grace while being extremely conscientious and ensuring a lot of (the right) progress is being made on many fronts.
You are not necessarily responsible for doing anything, but you need to be helping/solving/serving/encouraging and otherwise unblocking at every turn with a steady hand to ensure everything comes together as a whole. As my tennis instructor used to say, “Crazy feet, steady hands!” Keep this adage in mind as you lead your next product initiative, it has served me well.
As organizations make the shift to a product oriented delivery pipeline, product value stream leadership becomes critical. If you step into this new role, I encourage you to lead with your whole body. You will become a valuable technical product leader in your organization and generate more value for your customers.
