In 2007, I co-founded and subsequently ran a company named Apprenda. After the first few months of interviewing engineering candidates, we found that, while we got a sense for someone’s intellect and bias for collaboration, we weren’t very good at assessing someone’s actual real-world development skills. Brain teasers, on-the-spot algorithm questions, and on-the-spot “write code on a whiteboard” approaches were either inadequate or unfairly penalized candidates given the undue pressure of the circumstance. Instead, we decided to create a take-home exercise that, without a huge time investment, would give us a better sense of a candidate’s real-world performance. We created a basic scoring card and formula, looking for things like variable naming, adherence to OOP principles, and about another dozen dimensions we wanted to measure. We were primarily looking for evidence of strong code quality and structured thinking. We received lots of submissions. They were all variations of source-code, some IDE-generated documentation, and occasionally, a simple CLI.

In mid-2008, we interviewed a candidate that blew our socks off. While the actual interview was good, it was their take-home submission that was exceptional. What made it exceptional? They delivered a product. They submitted extremely well-thought-out source code, detailed code-level documentation, a full-blown graphical UI, a simple installation wizard, and an end-to-end, easy-to-follow walkthrough. The only thing missing was an LLC and a support number. Obviously, we hired them and they ended up working for us as one of our highest-performing engineers for over 5 years. We changed our scorecard to meet the high bar this submission had set; only submissions equal to or better could score a perfect.

The real impact this person had on me was inspiring me to evaluate all work output, even my own, through the product lens. It taught me that the best performers treat Everything as a Product (EAAP). The best performers I’ve ever worked with follow this EAAP mantra religiously. They behave as if they’re crafting something that will be sold with market-dominating intention, even if all they’re working on is a slide deck for a meeting or a workbook providing a financial analysis or forecast. These top performers either learned this behavior at some point in their lives or operated in the mindset instinctively. But does everyone treat their work output as a product? Not really. The inverse is also true: the poorest performers are those who, when they create anything, create it as if they’re the only possible customer of the thing they created.

“Come on Sinclair, not everything is a product. I’m a [choose your career], and I work on [choose your deliverable]. I don’t make things for others to use.”

The fact is, you get to choose whether you treat the output of your efforts as a product. It isn’t dictated by your career choice or job description, and in most cases, it isn’t even dictated by your boss or the organization you work for. Do you live in Excel or Google Sheets building financial forecasts? Work on marketing material? Write code that only you’re going to look at? Work on a speech? You can treat any of these as if they were a product to be used by the masses. A simple litmus test to determine whether you create something worthy of being called a product is as follows:

  1. You’ve created a roadmap defining the iteration and milestone, consumption-ready deliverables of the work. That ‘roadmap’ could be an actual roadmap for something being written in code, an outline of a slide deck, document, or workbook (along with milestone ‘drops’ for how you plan on releasing it), or any other shaping agent to drive your work efforts.

  2. You assume that the product will live forever. In reality, very little of what you do will be short-lived, even if you think it will. Imagine how differently you’d approach your work flipping the assumption of your work’s longevity.

  3. You can blindly hand it to anyone (the “Recipient”) that has the minimum expertise needed to understand the product, and they can use it maximally without your involvement beyond the handoff. Similar to (2), even if you think you’re the only consumer, it’s extremely unlikely that your work will exist in isolation. Acknowledging this will help force you into a product mindset.

  4. The Recipient can hand it off to anyone else meeting the criteria in (3) and produce the same result as listed in (3). This is the most aggressive test of the veracity of your works’ product readiness. It means that anyone can not only consume what you’ve built, but they can likely extend what you’ve built.

Although there isn’t a surefire way to guarantee that you’re treating your work output in the EAAP way, there are some things that I’ve myself learned or observed in the behavior of top-performers that can shape one’s activities to be EAAP aligned. Two of the most impactful have been:

  1. Provide your work a ‘Cradle to Grave’ featureset:

    By providing any consumer of your product an easy way to start immediately accessing value (cradle) and also be able to abandon that value (grave), you’re aligning your work with an EAAP mentality. While the installation-wizard example at the beginning of this post is obvious and easy to intuit, how do you build ‘Cradle to Grave’ functionality in, say, a financial forecast? You would provide an ‘Instructions Sheet’ that gives people clear direction on how to navigate the workbook, you’d color cell backgrounds for cells that allow variability/input, you’d leverage data validation for cells that only take fixed input, etc. This ensures that anyone who needs value from your workbook gets it as quickly as possible. Even if you’re the only consumer, this will, at worst, help you remember why you made certain decisions and ensure lower error rates. At best? You can take a vacation and not be bothered by questions because the answers are baked into your work.

  2. Choose one seemingly small core feature and make it unreasonably high quality:

    I’ve always stressed out over slide formatting. Obviously, everyone should care about what visuals they use and how they organize text; it’s what effective slides do. Inspired by Van Halen’s need for attention to detail many years ago, I have since made it a point to make sure that I used fonts consistently across my slide decks. This level of pedantry wasn’t in vanity; instead, it forced me to go through the deck dozens of times. Each pass through, I’d find some other side-quest improvement to make. Focusing on the details, such as font consistency, has shaped my behavior to pay attention to important dimensions that I may have otherwise glossed over.


At Nuvalence, we obsess over taking a product-driven approach to everything we do. It’s imbued in our culture.

We actually brought over the same exercise I had originally created at Apprenda and have made it part of our interview process. Whenever we evaluate anything, we evaluate it through an EAAP lens. We hold ourselves to this high standard. We teach our clients and their teams and partners to think this way, too. The reason? Because when working on important problems, it’s the only way to guarantee impactful solutions.