Sam Gimbel

Tech, Beer, and Strange Thoughts.

Product Manager Screening Questions

Tell me about a great product you’ve encountered recently. Why do you like it?

At DigitalOcean I spent a fair amount of time with CoreOS, a Linux distribution focused on developers and targeting clustered, highly available applications. This is done by leveraging linux containers and several open-source projects that CoreOS backs. I’m a big fan because it manages to draw in its intended audience organically, has significant revenue potential, and still manages to stay open-source and developer-friendly.

It’s not been long since Docker received VC funding for what amounts to a productized Linux function, and CoreOS has managed to find a large competitive advantage in the same space by providing a Linux distribution that removes the major pain-points of maintaining your own tech infrastructure. CoreOS targets developers who build apps rather than Ops folks by making clustering and app maintenance relatively painless, meaning your app has higher chances of staying alive when something goes wrong. This provides an incentive for small teams to use CoreOS to lower overhead typically spent on Ops early in a project’s lifecycle. This decision is made even easier due to CoreOS being free to use, platform agnostic, and open-source.

Most importantly, CoreOS makes money. This is ultimately the reason why it will succeed, transforming it from just a good idea into a great product. You can use CoreOS for free, but if you want to get the most out of it you can pay them to manage hosting for you, further simplifying your team’s infrastructure at a fraction of the cost of an Ops person’s salary. It’s clear that CoreOS understands this to be their key to success, having just opened a beta for another paid option: Tectonic, a Kubernetes-based managed platform running on the CoreOS stack. The forward momentum displayed by the CoreOS team along with the laser focus on app developers makes CoreOS a force to watch in the infrastructure space.

How do you know when to cut corners to get a product out the door?

There are four basic reasons to cut corners during the product development process: up-front scoping problems, major changes in the business or competitive landscape, newly uncovered technical realities, and poor timeline estimation.

It’s the job of the Product Manager to minimize scoping issues up-front by properly decomposing problems into MVP-sized chunks. Thus, if the PM is doing her job, this should rarely be a reason for cutting scope down the line. In the case where this does occur it is necessary for the PM to speak with his stakeholders to determine where uncertainty remained at the onset of the project so as to avoid scope changes mid-stream in the future.

In the case of changes to the competitive landscape, effective analysis of the change is necessary to decide when and how to cut scope. Typically we design MVPs to maximize ROI, where investment is measured in time, money, and product debt (a major side-effect of bloated scope). Changes to business realities require teams to either speed up, spend less, or change scope. In any of these cases we expect scope changes to happen only following a recalibration with stakeholders to verify what value still needs to be delivered, and what value—if any—can be sacrificed in order to adapt to the new reality.

In the case of newly discovered technical realities, we sync with Engineering in a safe space to understand the implications of continuing or changing course. If we can accept the change in schedule, we forge ahead, but only after verifying this with stakeholders. If we cannot accept the change, we negotiate with stakeholders to find a way to deliver the same business value through a modified implementation while attempting to anticipate the impact on the project’s timeline and budget.

Poor timeline estimation is both the most human and least predictable timeline hiccup a team will experience. Estimation issues need to be addressed as early as possible with stakeholder input to determine if corners must be cut, i.e. the value being delivered is time sensitive. This is done by determining whether value is reduced by spending more time on the project, and if so, how much time (and thus scope) needs to be cut in order to deliver value.

In any of these cases the most critical portion is continually keeping an eye on the ROI calculation at the end of each iteration. We can easily add more iterations to deliver higher value, and this is frequently a better option than cutting scope for the sake of delivering more quickly.

What aspects of product management do you find the least interesting and why?

My PM ‘flavor’ skews towards the UX end of the spectrum. As a result I find data analysis to be a necessary evil for which I have yet to develop any affection.

First, let me start by saying I fully recognize the need and value of making decisions based on good data, especially at organizations where product-market fit exists and scaling is priority number one. It’s a large portion of any good PM’s job, and rightfully so: it’s impossible to know which direction to explore without good market intelligence, and this usually falls upon the PM to gather.

Data analysis is a precursor to the portion of PM work that I enjoy the most: the user-focused prototyping phase during which real people give feedback that can be distilled into behavior patterns and eventually better products. This means that analysis is frequently all that stands between me and the part of product management I enjoy the most.

What’s one of the best ideas you ever had?

The DIY music scene has exploded over the last ten years as the cost of high-quality digital recording has decreased and interest in programmable synthesizers and live DJing has increased. While producers and digital musicians have reaped the creative rewards of this renaissance, analog musicians have lagged behind, hampered by the largely proprietary nature of amplification and digital sound processing.

There’s a huge opportunity here. I propose a fully-open, highly-configurable hardware platform with support for already-existing recording software standards. The design is modular: it looks like a typical guitar amplifier, and in the spirit of Arduino and LittleBits every module is hot-swappable for different purposes. The hardware is tied together through plugins to popular recording software, making it easy to control your sound live from the sound booth or a footswitch. The result is a system in which any musician can find their sound by buying or making their own modules, either through the hardware system or by programming digital effects processors through the software layer.

The benefit for the musician is obvious: control over your sound is paramount to creating the music you hear inside. The business value lies in creating a platform focused on musicians who contribute back to the community: while the platform is open, purchasing pre-made modules as well as the unit itself will drive revenue immediately in the MVP stage. And, given the relative simplicity to manufacture the modules themselves, the profit margins per-unit could be quite high. There are clear applications in the hackerspace and music education worlds as well, which typically get overlooked by mainstream instrument manufacturers.

What problems is Percolate going to encounter in a year? Two years? Ten years?

Percolate’s vision, to be the system of record for marketing, leaves plenty of room for additional feature development through the next few years. Beyond that horizon, however, there is a lot less certainty regarding the value that can be added through incremental feature development. In 10 years Percolate will have to already have developed a vision that allows for multiple verticals or further segmentation within the existing vertical, all while continually responding to changes in the way companies do their marketing. This last problem cannot be over-stated: while marketing has changed drastically in the last ten years, the rate of change will only continue to accelerate in the next ten.

There is a lot more certainty at the one-year horizon. Percolate has shown it can sign large clients with recognizable brands. Because there are a limited number of companies of this size, continued growth in the up-market segment will require stronger and potentially expensive sales tactics, which will in turn place pressure on the product development organization to respond to the needs of the client segment without falling into the trap of taking ‘specials.’ Staying focused on the existing vision and strategy will become major challenges in the next twelve months.

One year is not enough time to significantly alter product strategy or market positioning, but two years is. Within two years Percolate will be challenged by the need to find new audience segments: will we continue to focus on up-market brands or will we develop lighter-touch solutions for smaller companies? Moving down-market implies new acquisition strategies, a more nimble product offering and roadmap, as well as a sustainable strategy for continuing to support the existing larger, higher-revenue customers. All of this must be supported by the product team and understood by the full Percolate organization, which implies the hardest of all changes: a culture shift. This will necessarily affect all decisions made after this point, as well, so considering the 10-year vision at the 2-year mark would be helpful to avoid future changes in culture.