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-Read More »
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.Read More »
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.
The topic of generalists vs specialists always comes up in PM hiring and strategy conversations. I see PM hiring managers and PM’s themselves struggle with this a lot. What got me thinking about this topic is David Epstein’s new book Range. The core thesis in the book is, and I quote, “Range explains how to maintain the benefits of breadth, diverse experience, interdisciplinary thinking, and delayed concentration in a world that increasingly incentivizes, even demands, hyperspecialization.” So how should you think about this topic? What are the nuances?
The anti-pattern I’d like to explore today is what I affectionally call the head of problemaka senior’itis. In my experience, this is the factor in org design that increases burn and bureaucracy. This anti-pattern is lethal for companies.
It starts off quite innocently. Let’s assume you are the CEO at the early stages of a company and you have identified a problem to solve, say in the general area of customer support. Customer support as a function doesn’t exist yet. You ask around your peer group, you look at successful companies and then you make the common mistake – you get afflicted by senior’itis. You decide that you need somebody senior to run that function, you need somebody who has done it before somebody with pedigree. You need a Head of customer support. You then spend a lot of time trying to woo the right candidate, the one that checks all the boxes. You hire him after a long drawn out courtship. You are happy, your customer support problem will be solved, you have found the right person. You have hired a person who will take accountability to solve the problem.
The next few posts are going to be about anti-patterns. These are all about the landmines you should try to avoid – learn from my mistakes :). Almost all problems in companies are people/organizational problems. Hopefully, these set of posts can help you navigate through some of the nuanced ones.