14 lessons over 14 years
Updating this post after 2.5 years at Amazon to add more more learning… Original post from September 2022. Here is the most important lesson I learned in each year of work thus far. 2011: Software Engineer –> Designing a Data Warehouse is a technical and usability challenge. Ideal to have a single very wide table at lowest level of granularity (view or physical depending on database). Everyone messes up joins. Avoid duplicates. Pick descriptive and long column names. 2012: Solutions Engineer –> Cohort analyses are extremely helpful in understanding your customers (e.g new/loss/gain/churn over time). When in high-SKU domains (e.g eCommerce) product affinity analysis is also extremely valuable. 2013: Sr Solutions Engineer & first management role –> Engineering leadership must be done from the front. Communicate consistently and clearly explain priorities. If the team is staying up all night for a release, you are too. Hold yourself to the standards you hold the team to. Get coaching and learn. Listened to Manager-Tools Podcast and learned “When you tell a group of people something 7 times half will say they hear it once” 2014: Technology needs its own multi-year vision. Company, product and/or customer driven roadmap is not enough. Focusing on a core customer goal (High Availability for our largest client) led us to a multi-year delay in a more long-term important technology requirement for our business (native AWS). 2015: Director –> $500million acquisition! I led product demos + technology due diligence with prospective buyers. Before the deal closes there is a multi-year investments in relationships, clear narrative, consistent performance against prior commitments, demonstration of deep bench, and enthusiasm of all the principals. 2016: When something is working let it rip! I served as engineering + product leader for a segment of our business that hit $10m ARR in 18 months from launch. With just 3 engineers (and ~5 GTM folks!). We did this with extreme focus on customer needs, good early architecture decisions, and a very cohesive and strong team. Once growth hit this inflection point we should have invested dramatically more to define category and deepen moat against incumbents who had more distribution. We grew business to ~$25m ARR but it could have been $100m+. 2017: VP –> Recognition is the ultimate incentive. Money is a critical form of recognition (especially in a competitive market!) but in the end most people strive for status and recognition. Culture is defined by recogition and created with thoughtful org structure and operating cadence. Critical when balancing mission vs functional teams, creating career ladders, deciding compensation, and in creating org rituals. 2018: SVP –> The faster you need to execute the fewer objectives you must have. Narrow and prioritize. Then cut again. Dramatically increase expectations of quality and speed while dramatically decreasing number of projects and ‘decision makers’ 2019: Sr PM at Slack –> Small companies have drama, big companies have politics. Understand the coalitions and competing goals. With many Type A people getting things done requires (1) willingness to heads down make decisions and ‘ask for forgiveness’ or (2) building coalitions for your cause. Know which strategy to employ in which circumstance. 2020: Brands matter. A brand is the expectations and emotions people associate with something. McDonald’s brand is so strong because it is consistent. Work to clearly communicate consistent expectations of your project/team to stakeholders (and follow through!) 2021: Proximo –> Stated vs Revealed preferences are very different. Social desirability bias is real. Potential users unintentionally lie during user interviews to (1) be nice to you and your ideas, and (2) showcase the best aspirations they have for themselves. Be careful to suss out true challenges and avoid solutioning too quickly. 2022: Proximo –> People respect tough decisions that are made with clarity. Customers, employees, investors all understood decision to shut down Proximo. I also strived to take care of people - getting the team great jobs, returning remaining capital to investors, and helping customers find alternative solutions. 2023: Amazon Sr Software Engineer –> After 10 years in management joined Amazon as a Sr IC writing code again. Reminder that you can just do stuff, even for big companies. Keep finger to pulse on technology, took external idea from papers/blogs, built working prototype, and proposed new personalization system that ultimately improved CTR for homepage recommendations. 2024: Amazon Software Development Manager –> Back into management, this time leading AI Shopping Guides from prototype to public marketing launch. Learned how to build high quality accurate products using LLMs, manage the scrutiny of high profile projects, build 0 to 1 teams in a big company and, mostly, move very very fast.
Tips for working at a bigger company
Transitioning from startup to larger companies can be a huge shift in mindset. I made the shift from a 250 person startup (I had worked at from 30 → 250) acquired for $500m to Slack in 2018. Slack was then a pre-IPO company with 1200 employees (grew to 2000 in 18 months). I struggled! It was significantly different and harder than I expected. In personal conversation with startup friends transitioning to larger companies I’ve given advice on how to handle this better than I did. I decided to type it up for re-use. Like most advice this is a form of nostalgia so YMMV. ...
Products & Platforms pt 2 - from Desktop Windows to AWS
Rise of Windows & Enterprise Licensed Products The first wave of enterprise products built for mass adoption by office workers were built largely on top of the desktop computing platform of Windows (which of course Microsoft was able to build because of IBM’s decision to let them own the OS). Windows allowed developers to build products for the entire enterprise market regardless of the hardware they purchased. Developers could build for one platform and have a major market immediately open up to them. Domain expert products covered areas like computer aided design (AutoCAD), graphic design (Adobe), and financial analysis (Peachtree, etc…). ...
Products & Platforms
This post covers two axis in product positioning - product vs platform and licensed vs service. My goal is to help product leaders and companies think about where their offering really competes and what it means to win there. Horizontal Axis: Product vs Platform Products are discrete offerings where the key relationship is between the provider and the customer. Think Dropbox, Gmail, Excel. Innovation: Products win through profound understanding of the end-user persona (I just want all files to sync without ever thinking about it) and building the most seamless user experience for them. Products build moats around their existing user base, via data network effects or skill-set (e.g Excel as first spreadsheet reliant on GUI and a mouse) Distribution Channel: Products are distributed by a platform - Operating System, browser, app stores, public cloud. This is how users will discover and sign-up for the product. Deciding which platforms to support is key to balance distribution with trade-offs in customer relationship, cost, user experience. Platforms are distribution channels where the economic value generated by participants in the ecosystem is higher than the value generated by the owner of the platform. Platforms enable partners to build entire business atop of them, only taking a tax. Think AWS, iOS, Browsers. ...
Startup Manager Dos and Don’ts
Becoming a first-time manager at a startup is hard. Given the intense pace and growth, you are often promoted with limited training and expected to manage people who used to be peers. You are asked to continue to deliver on individual contributor responsibilities – write code, support customers, or sell, while also managing a team. After going through this transition myself, and helping coach dozens of other managers through it, I wanted to put together a curated summary of the best advice I’ve gotten. Let me know what you think: ...
How to Give a Great Demo: Part 3 – Answering Questions
If a demo is going well, your audience will pepper you with questions. This is a great sign of an engaged audience. It gives them the chance to focus on their key topics. Unfortunately, given the open-ended nature, many new demo’ers find answering questions to be particularly challenging. This blog post will give specific advice on how to handle questions. Rule 0: DO NOT CUT THE PROSPECT OFF This is so fundamental it is both rule 0 and written in caps. No one likes to be interrupted. When you interrupt a prospect it comes across as arrogant, or worse, dismissive. Remember, you are talking for most of the demo. The prospect wants to feel heard and understood. ...
How to Give a Great Demo: Part 2 – It’s About Stories
“If I had had more time, I would have written a shorter letter" Blaise Pascal 1 As Pascal notes, it’s hard to be concise. This is especially true when demo’ing a complex enterprise application. Unfortunately, our audience has trouble following a complex idea along on a longwinded feature focused demo. This makes it our task, as demo’ers, to break each key point into a short digestible story. I call these vignettes. ...