An antipattern that I see in startups constantly is Senioritis. This normally happens when the startup finds some success and wants to upgrade its product and engineering teams. Typically at this stage, new leaders are hired and there is a we need to grow up vibe. These new leaders typically are hired from established companies/startups and bring with them their approaches. Continue reading “Premature optimization is the root of all evil”→
Accountability is one of those topics that sounds super easy but is the hardest to get right in practice. A recurring pattern in organizations is
The top of the totem pole (exec team, org VP’s) get together and decide the strategy for the year
It gets broken down into priorities and goals for the year
Its gets documented and passed downwards via some process
The entire organization references the document and should have visibility into priorities and be completely aligned
Starting from the top every node in the hierarchy points to the document and downward and says I hold you accountable to this. This process continues until you reach the individual contributor at the bottom of the tree.
The organization achieves 30% of what’s on the priority list
The accountability stack unwinds upwards with the feedback that either
The goals were not clear
Stuff changed midstream
Reasons why the goal was missed
Go back to Step 1
This loop repeats like clockwork. Welcome to accountability theatre.
My current obsession is the topic of signaling. Julie Zhou posted an interesting newsletter last week about team dynamics and feedback. The central theme in her post was about creating a document called the user guide to you and how it helped her level set with her team.
Something about that post didn’t sit right with me. It made it to hacker-news and the comment section gave me a few clues on why I had such an allergic reaction to the post. I have had to a few times in my career, write a user guide like Julie described. I’ve always found it uncomfortable, but never dug deeper. I wrote the document and carried on, treating it as a piece of paperwork that I have to get out of the way.
A compendium of the advice that I can impart to aspiring writers. None of this is rocket science! Take what is useful to you, whatever makes you write – go for it!
Have a why that is inwards focussed
Channeling my inner Simon Sinek, the “why you want to write” is the most important thing to get right. Are you writing because you like writing? because you want to build a brand? because you want to learn something? My #1 tip is to focus on the inward reasons rather than the outward reasons. Most folks I talk to approach it as a brand- Continue reading “Writing strategies for the beginner”→
First an announcement. I have jumped on the newsletter bandwagon and am on substack 🙂 It’s an easier way to consume content – you don’t need to come back to the blog week after week, my posts will arrive straight to your inbox. Subscribe here.
And now back to our regularly scheduled programming. Today’s topic: How should product organizations change due to coronavirus?
So I’m a GM now :). Learning by writing is my thang so the next few posts will be about all things GM. Hopefully, fellow GMs and my core constituency of product folks will find this interesting and useful! The GM role in tech companies is a broad role that is accountable for a commercial (revenue and or profit) number. A GM has three levers of Product, Sales, and Marketing to achieve this outcome. Coming from a product and engineering background it was instructive to me to understand how sales and marketing differ from the product and engineering function. These are my observations/learnings from the few months on the job!
The last post was about what to avoid, this post is about what you can do to make a migration successful.
Sequencing is key
With any large initiative, the natural impulse is to throw a lot of people at it. Avoid this impulse at all costs. At the beginning of the project, it is better to have a small team of your crack developers and senior engineers and PM’s to focus on building a skeleton of what the end state would be like.
At some point in your product career, you will do a systems migration or a system rewrite. In this two-part series, let’s explore some lessons learned. This first post is about the things to avoid before starting a systems migration. The second post will walk through some practical tips for organizations on the most efficient way to pull this off.
To set the stage – How do you get to the point of needing a rewrite in the first place? The general arc of startups starts with an MVP that is designed quickly. It’s all lean in the beginning, this is the MVP phase. Most backend processes are manual. It makes sense – you don’t know if there is product-market fit and so you don’t over-engineer and make a full end to end software solution. As you find product-market fit, your user base starts growing exponentially and you enter the bolt-on phase. There isn’t enough time to slow down and add incremental features to the core product to make scaling easier. So you start bolting on hacks on top of hacks, pseudo automation based on excel macros and more policies and procedures to keep up with the growth. Your software system now gets to spaghetti level status. Continue reading “Platform rewrites, lessons learned”→
I’ve always been interested in figuring out what signifies greatness in PM, what makes a great PM?
A source of signal for me has been the ability to deal with ambiguity. Great PMs have this innate ability to take ambiguous thoughts/ideas/strategies as input and come up with a coherent executable plan which then they execute ruthlessly. A great PM has the superpower of bringing clarity to everything.