I’m often asked “what does a fCPTO, really”? That is, fractional Chief Product Technology Officer. I thought I’d break it down into some real activities that I’ve done recently.
Product Link to heading
Customer Interviews Link to heading
I’m generally talking to more customers than anyone (aside from the sales team). The goal is to understand the customer and understand the market. You can think of these as demos in many cases, sometimes with the real product, sometimes with mockups, and occasionally rawer interviews where we talk more about pain points. The goal here is to know what the customer needs and when they need it - what product-market fit looks like, and what you need to do to get there (or what you need to do to stay there).
One exciting opportunity AI has unlocked is the maintenance of a customer interview library. With accumulated transcripts, you can ask the agent for analysis of gaps and opportunities.
Roadmapping Link to heading
One of the core functions that Product needs to do is provide an actionable roadmap. This isn’t meant to be gospel - the map is not the territory. But it provides a documented set of priorities that can drive discussion within the organization. Of course, these should generally be drawn from the customer interviews. With a roadmap, you can start prognosticating about when things can be delivered (and what to cut to get there).
AI can unlock quick roadmapping if you give it adequate document context, but I’ve found the real value comes from forced alignment. That is to say, forcing your stakeholders to argue about what’s most important.
Pricing and Packaging Link to heading
I’m often called in to do a review of pricing and packaging. What I look for here is a gradual “stair” model, where at each step a user can access some set of functionality, while unobtrusively being made aware of the “next” set of features. This involves some amount of creativity, mixed with customer feedback (charge more for things that are more valuable!). Many companies stay on a single option when some amount of price discrimination can make the product both more profitable and more economical for the customer. As a simple example, with more options a churning customer might choose to downgrade rather than leave.
Requirements Link to heading
I’ll usually also be involved in directly putting together product requirements, and bringing engineering in to review them.
Technology Link to heading
Org Design Link to heading
This encompasses hiring, firing, and retention, with everything else like career frameworks or ladders, onboarding, and so on. Critically, each function within the organization needs strong ownership. This usually involves starting with pain points (low velocity is a classic), and root-causing from there. Some organizations needs additional headcount, some need less, and some need to do more with less. I try to make myself available for mentoring and growing the existing staff, and use that as insight into what next steps need to be taken. Once ownership is established and an effective engineering culture takes hold, following changes become much easier (or possible).
Integration Link to heading
Many engineering organizations think that work begins with requirements, and ends with closing a PR. This is false. The software value chain generally starts and ends with sales & marketing. At minimum, Product depends on engineering feasibility to evaluate timelines. As such, I try to bring the engineering organization into contact with Product (through feasibility syncs, early) and with other departments (shadowing, regular syncs, coffee breaks).
Execution (Table Stakes) Link to heading
Then follows the table stakes - execution, and execution enablement. I’ll usually take over ownership of some fragment of the codebase directly (usually something relatively tangled, where ownership is not fully established). This provides an opportunity to show existing employees what “good” and “fast” can look like. As such, I’ll set up office hours for consultation, review many PRs, and begin producing ARDs (architecture requirement docs)
There’s a lot more that I do regularly that doesn’t neatly fit into this too - as an example, I’m often leading UI/UX redesigns of certain hard to use components. There’s a lot that goes into the role - it’s incredibly broad.