Then the slow crawl to the office, the kind that tests your patience before the workday even begins (in this case, I’m referring particularly to Bangalore traffic).

Once you’re there, it is not just design work. It’s aligning with PMs, unblocking engineers, giving feedback, getting feedback, defending design decisions, documenting stuff, and navigating a dozen micro-pivots before lunch. Mental energy burns fast.

By the time you’re home, the day has already taken its cut. Some of us squeeze in a workout. Some meet friends. Others collapse on the couch.

And then there’s that small slice of time that’s truly yours.

What do you do with it to grow as a designer? Where do you invest effort and time?

Do you sharpen your craft until your work speaks for itself? That could mean diving deep into motion design, storytelling, interaction design, visual polish.

Or, do you lean into code? Front end skills, AI prototyping, building in tools like Framer, becoming the designer who can ship ideas faster and speak an engineer’s language?

The pace of change is super fast. If you focus the next 6-12 months on the wrong skills, you might miss opportunities you don’t even see yet.

So I asked designers—ones just starting out, those in the messy middle, and leaders who’ve been where we are now. I’ll try to describe in the best words, what they all said.

How this article is structured

Each section will focus on one group. Each group is a level of designers as mentioned below. I’ll share a quote or sentiment that stood out from my conversations with them.

And then a few bullet points capturing the essence of what they’re really saying.

Levels

• Early-career (Associate product designers, product designers)

• Mid-career (Senior product designers, lead product designers)

• Design leaders (Design directors, S/VP of design, head of design)

What early-career designers say

“I’m not interested in picking up coding from scratch. But if there are tools that let me achieve outcomes, I’d try them, especially if they help with design outcomes.“

—Sharanya, Product Designer

“For someone like me, who wants to explore other design disciplines, I think craft is very important. But I think AI tools help me cut the execution time down and explore craft quicker.“

—Ronith, Product Designer

• Many early-career designers lean toward craft because it strengthens core skills that apply in any industry.

• AI tools are seen as an enabler, removing heavy execution work so more energy goes into creative exploration.

• Craft means not just visuals, but thoughtful articulation of why design choices are made.

• Technical tools and AI aren’t a replacement for craft. They’re a medium to express it better and faster.

Surprisingly, early-career folks are much more open to exploring AI tools than mid-career designers.

What mid-career designers say

We’re essentially walking the tightrope between craft and code. We want to do the right thing, just don’t know which way to lean. And LinkedIn is no help either. Everyday either coding is dying or design is dying.

“Craft can be a personal pursuit. But in most real-world projects, your success depends on how well you understand technical systems and how quickly you can work with them.”

—Isha, Senior Product Designer

• Feeling the pull from both sides—code/AI trends from teams like Google, Intercom, and Raycast vs. the satisfaction of mastering craft.

• Recognizing that coding skills improve collaboration with engineers, and can open product leadership doors later in your career.

• At the same time, knowing that your role is still anchored in design craft. Motion, visual design, strong interaction design, and storytelling still set you apart.

• Some are experimenting with split learning schedules (I’m doing this. Code and prototype in the morning, motion in the evening) to see which one sticks.

• Realizing that craft excellence drives performance reviews today, while technical fluency might shape your opportunities tomorrow.

• On the job learning might help in learning AI prototyping, but craft might be a personal pursuit.

What design leaders say

When you talk to design leaders, the conversation shifts quickly from tools and trends to bigger questions like purpose, impact, and the kind of a designer you want to become.

Their advice blends decades of craft with the realities of running teams (sometimes whole orgs), navigating org politics, and shaping products at scale.

“What pulls you in? Discover what gives you happiness and pursue that. It can change over a period of time, but find your purpose first.“

— Amit Chowdhury, Adobe India Design Leader

“The future lies in outcome-driven, solution-centric designers. I don’t think craft will ever be at the center anymore. You’ll have to be an everything designer very soon.”

—Mohit Yadav, Founder & Chief Design Officer - Wolffkraft

• Get clear on your life goals. What kind of work makes you feel alive? What gives you lasting satisfaction and happiness?

• Choose a path based on what pulls you in, not what’s trendy.

• Strengthen craft. Things like visual competence, thoughtfulness, and attention to detail still matter.

• Learn to speak the language of PMs and engineers. Understand their decisions before challenging them.

• Blend craft with the ability to create measurable impact for the business and users.

• Build leadership skills early, even if you’re not in a formal leadership role yet.

• Go broad over time—stack new skills on your core instead of sticking to one lane. Learn everything you can.

• Design is about serving others.

My two cents on the topic

If there’s one thing that stood out to me after all these conversations, it is this -

Learning the “build” side of things feels like the smarter bet in the short term. AI tools, prototyping, technical fluency—they’re not just nice-to-have anymore.

But here’s the catch. None of that means craft can be sidelined.

Craft is what makes a product delightful, thoughtful, and worth using in the first place. And in a sea of AI-generated sameness, strong craft will stand out even more.

Personally, craft still calls to me. I’m drawn to it because it feels rare… something not everyone can master. But I see myself building products in the future, I know I need to sharpen my build abilities too.

Feels like it’s not an either-or anymore. It’s craft for depth, build for reach. And both are needed for a seat at the table designers have always been longing.

What do you think about it? Comment below, on LinkedIn, or Twitter.

We got featured!

This post was featured on E.P.I.C Journal — a design community resource by Wolffkraft and Extended Pack Collective (EPC).

➡️ Read here

Imagine that… an entire product’s responsibility thrust upon a young individual who hardly knows how to file taxes.

At the same time, I realized that first design hires (fondly known as founding designers) make a lot of mistakes. No one can blame them. The role is such.

As a first hire, you set the bar, you decide on the design language, you deal with founders directly—who often don’t know what design is all about. I’ve been there. I’ve dealt with being the first design hire more than once.

Tried to put all the lessons I learnt into this guide. I hope this helps you. For everything else, my LinkedIn is always available.

Before you read further…

Just a small note…

I’ll be writing less often here. Probably once or twice a month. I’m making space for a new initiative I’ve been excited to work on for a while now.

This also means I get to spend more time on each piece and write about things that truly matter to me and hopefully to you too.

Thank you for reading and being here. It means a lot.

Welcome to the chaos

First of all, there’s no playbook for this. You join, and by day 2, you’re expected to revamp the onboarding or bring that Apple-level polish. No design system, no research, not even clarity on who the real user is. Sometimes not even product–market fit.

You’re expected to figure it out.

0 to 1 is super scrappy, ambiguous, and often overwhelming. You’ll hear things like:

“Why is this taking so long?“

“Can’t you just fix the UI and be done with this?“

“Can you give me the company logo in high quality?“

“Make it look premium“ (on a shoestring budget)

“We don’t need research. The PM knows everything.“

Now that you feel understood, let me tell you an important realization after designing for several years—chaos isn’t the problem. Lack of clarity is.

Clarity on your part about the job, clarity on the team’s end about the product vision, clarity on every non-designer’s end not knowing what it takes to actually solve problems using design. The list is endless.

So, in your entire FDH (I’ll refer to you as first design hire going forward), your priority will be to find clarity, create clarity, collaborate to reach clarity.

Navigating the people

As an FDH, you might report to a founder, a PM or... no one in particular. Either way, you’re probably surrounded by people who don’t know what a designer does.

A part of your job is showing what good design partnership looks like.

• Start with listening, not proving. Everyone’s invested in the product. Instead of telling them what’s broken, start by asking what’s not working for them. You’ll earn trust quicker this way

• Treat engineers like partners. You’re not their boss. They’re not your boss. You’re equals. A 15-minute handoff session can turn blurry ideas into something everyone takes ownership of

• Don’t get attached to every piece of feedback. You’ll hear a lot of opinions. Some useful, some… not so much. Learn to extract intent instead of reacting

• Respect urgency of the business. This isn’t Google or Facebook. There’s probably only 6 months of runway left. So, if you’re wondering why no one cares about typography at the moment, that is the reason. Help where you can

• Over-communicate your process. No one understood the effort it took to arrive at the stuff I delivered. So, I started showing people user flows, iterations, wireframes and research in every handoff call. A messy FigJam screen is all it takes for someone to respect the work you do

Navigating the work

You’re probably designing onboarding, the dashboard, a new feature, the pitch deck, and the landing pages, all at once, sometimes in the same week.

That is the reality of 0 to 1. The sooner you accept it, the better you’ll fare.

• Don’t aim for perfect. Start with momentum. Progress beats polish in a startup where speed is survival

• Solve the real problems. Not only the exciting ones. Your homepage isn’t bleeding users, onboarding might be

• Keep documenting light. I made the mistake of starting with an extensive guideline list while creating the design system. Slowed me down quite a bit. No one will read a 10-page spec.. send a Loom or make a simple Notion page instead

• Make every decision a test. Try things. Watch what happens. Adjust and adapt. That’s how early stage products grow

• Care about the outcome, not the craft alone. I can’t believe I’m saying it, but you can’t always focus on craft. Measurable impact is super important to get funding, more social proof, etc.

Navigating yourself

For the nth time in this post, early design days can be messy. You won’t have a design team to lean on, no formal rituals to follow, and barely any time to pause.

In this chaos, you are your own structure. If you aren’t a person of grit, 0 to 1 isn’t for you. Least of all 0 to 1 design.

What matters most is learning to hold your ground, and investing in habits that keep you steady when nothing else around you is.

• Titles don’t make you senior, decisions do

• Find smart people who will critique your thinking, not your work

• Talk to users even when no one is watching

• Protect learning time like it’s a deadline

• Growth here is measured in peace, not polish

The best days in my 0 to 1 journey have been spent being proven wrong, not knowing answers, breaking assumptions, arguing about the best approach for a feature—all of which result in a great product experience.

A controversial opinion

This might sound harsh or pro-hustle culture, but you need your personal life squared away. A startup is putting a huge part of their business in your hands. That means something. There’s money on the line, livelihoods on the line, and if you have chaos in your personal life, it will trickle into work.

I like to get up early and work so that I don’t take time away from friends and family. I learnt to work with speed so that I can protect my time. I learnt to build trust so that I can take days off without being overburdened with work when I return.

It is simply unjust for you to not give your 100% to a business that just began. And it is definitely unjust for you to join someone’s dream just for the money and the inflation of title to “lead designer“.

Integrity should mean something to you.

Major mistakes I’ve noticed

A few traps are almost universal. I’ve fallen into some myself. Here’s what to watch out for:

• Getting too attached to your designs before they’ve proved any value

• Confusing a flashy UI with good product thinking

• Being okay with extensive UX without putting a drop of effort into the UI

• Over-inflating your title without the experience to back it

• Designing for Dribbble, not users

• Forgetting that speed and scrappiness matter more than perfection early on

• Only working all the time without taking care of learning, health or rest

You’ll make some or all of these mistakes for sure. That’s okay. Ask better questions, take note, and move on.

On making it sustainable

The hardest part is probably sustaining the speed and effort.

I’ve heard leadership take people out of 0 to 1’s every 2 years to let them rest a little bit. Not mandatory, but sustainable for sure.

You won’t always have clarity, feedback, or applause. So you have to create your own rhythm and set boundaries. Build habits that help you show up even when things are chaotic.

Consistency will keep you in the game longer than bursts of brilliance.

Wrapping it up

Recapping it all here:

• You’re not just designing screens, you’re shaping how the team sees design

• Learn to manage up, sideways, and with empathy

• Don’t chase perfect, ship, learn, iterate

• Process doesn’t matter unless it helps you move faster

• Focus on habits that make the work sustainable

I’ve said enough.

Time to build cool shit. Let’s go!

A repeat note… I’ll be writing a little less here to focus on a new initiative. Gives me time to write more thoughtful pieces here as well. Thank you for being a reader, I’m grateful.

Share

Don’t get me wrong—I have worked really hard on these skills and I believe they’re a big part of the journey to where I am today. But, I don’t think that’s the entire story.

There’s a set of underrated skills, invisible habits, that compound even though no one talks about them. Skills like being able to write clearly so you don’t need another meeting. Or knowing how to say no without ruffling feathers. Tiny things that build trust, influence, and momentum.

I’ve seen this pattern too often. So, here’s my attempt at giving you a list—non-exhaustive most probably—useful nevertheless.

1. Stakeholder specific communication

This might be one of the most underrated skills ever.

You can’t speak to a PM, an engineer, and a sales VP the same way, and expect to get anything done. The best ICs adapt their communication based on context.

They know that in a room full of execs, numbers speak louder than wireframes. When talking to engineers, they highlight feasibility and edge cases. And when aligning with design peers, they zoom into the nuance of interaction or visual language.

Research backs this up.

McKinsey reports that teams with strong cross-functional communication are 3.5x more likely to outperform their peers in delivering projects on time and within scope.

Alignment happens when people speak each other’s language. One misunderstood message in a sprint planning or stakeholder review can lead to two wasted weeks. Maybe more.

A few simple shifts that can help:

→ Replace “This feels off” with “This flow might confuse users, can we test two variants?”

→ Don’t show 3 concepts if a decision-maker only wants a final call

→ Start with what matters to them: ROI, risk, user feedback, dev effort

Bonus tip:

→ Front-load the win in a boring long pitch. Talk of impact first, and then the story behind it

2. Saying no without saying no

Great ICs know how to protect the product without burning bridges. You’re going to get unreasonable asks—bad ideas or last-minute requests.

Saying no outright can stall momentum, or worse, erode trust. But saying yes to everything is a fast track to bloated scope and mediocre outcomes. You know exactly what I’m talking about if you are a part of a product team.

Plus, saying no goes beyond work, into protecting your personal time.

The skill? Pushing back without friction. A few ways to do it:

→ “What’s the exact problem this solves for the user? Maybe there’s a better path”

→ “We can test this as a follow-up, once the core experience is solid”

→ “If we prioritize this, we’ll have to trade-off something else. Let’s decide together which ones?“

This is part of the positive office politics that everyone needs to learn.

3. Product thinking, no matter your role

If you work on a product, you’re already part of shaping it. Might as well do it well.

Here’s a frequently read article I wrote on feature shaping strategy by Basecamp:

The best ICs don’t wait for PMs to hand them specs. They ask:

→ Who is this for?

→ What problem are we solving?

→ How will we know it’s working?

A designer who questions feature creep, an engineer who flags UX edge cases before they ship, a marketer who aligns messaging with user needs, not just business goals… all this is product thinking in action.

Personal experience:

I’ve worked with too many people who don’t understand cross-functional skills, and generally don’t contribute very much to the product. This also leads to slower growth of the individual and an overall lack of strength in the team.

Try writing a PRD yourself, try talking to customers, try learning what an engineer or designer or QA does in your team. It helps everyone.

4. Writing > Meetings

Clear writing is the productivity hack nobody talks about enough.

Coincidentally, I’m reading How to Take Smarter Notes by Sönke Ahrens, because I want to step up my writing game.

When you write well:

→ You think better, produce better

→ You waste less time, remember more things

→ You bring clarity to chaos (a super rare skill nowadays)

Docs beat meetings. Always. Async updates, decision memos, design rationale, these scale across time zones, roles, and priorities.

Amazon famously mandates written narratives over slide decks in leadership meetings. Why? Because writing forces rigor. You can’t fake through a doc the way you can through a vague update.

Every team I’m a part of, I push my folks to do this. Strong ICs use writing to drive alignment, document decisions, and reduce back-and-forth.

5. Emotional regulation in high-stakes moments

High performers don’t just ship, they stay grounded when things go south. Products fail. A launch can be delayed. Feedback stings, a lot. I’ve been there…

In these situations, pause, process and respond.

This isn’t about being cold or robotic. It is about learning to separate temporary chaos from long-term goals. Success and opportunities gravitate towards people who stay steady under pressure.

In fact, a report by TalentSmart found that 90% of top performers score high on emotional intelligence (EQ). Regulating emotions isn’t soft, it is strategic.

This is the most important skill for leadership.

6. Translating between functions

The most valuable ICs act like bridges, not barriers.

They understand how to speak engineering without over-designing. They know how to simplify product requirements without watering them down.

They decode business priorities into creative decisions. No team works in a vacuum, and ICs who can fluently switch contexts make themselves indispensable. Very tightly connected to writing, communication, and product thinking.

You don’t have to be an expert in every function. But you need to understand what each team cares about. It’s the difference between pushing a task and getting buy-in.

7. Knowing how to create influence without authority

You don’t need the title of “lead” to start leading.

In product teams, formal authority can be rare. What you need instead is influence. That means rallying people behind a vision. Framing your ideas in ways that resonate with others. Getting people excited about the work, because they believe in you.

That looks like proactively sharing thinking. Creating clarity where there’s ambiguity. Backing up intuition with data, and listening hard when challenged.

Doing more than you’re expected to do.

And most importantly, knowing your shit very well.

You don’t need to work on all of these right away.

Start with one. Just pick one that you feel will unlock the most leverage in your current role. I’m taking up writing, cross-functional communication and saying no.

Wherever you are, start there. Don’t rush. These are the skills that quietly shape careers, other than your actual work skills.

Which one are you picking?

Pssttt….

I know I haven’t added any images on this post. An additional underrated skill is the ability to focus and read. The digital age has taken that away from us.

If you read everything till here, without any images, you’re already focused to a large extent. On to larger goals 🚀

“—“ is an em-dash, used to join thoughts together.

I use Option + Shift + “-” on a Mac to generate it.

If you liked this article, share it with your friends and colleagues. Show them the cool stuff you’re learning!

Share

Frankly, I’ve been lazy, and maybe a little protective, when it comes to frontend prototyping AI tools. Part of me thought they’d never match the level of work I’m doing. Another part of me feared that if they actually do a great job, my skills might become sort of obsolete.

But the moment I gave it a shot, I realized, it is only going to make me better at my job. This post isn’t about adding hype to the pile. It’s a simple, no-fluff crash course/impressions collection—what worked, what didn’t, and how v0 feels from a builder’s (and designer’s) standpoint.

Why I gave it a shot

I had it in my to-do list for a week before the PM I work with suggested I start my design process with v0. Sounded like the universe telling me to do it now.

Glad I did.

As someone who takes pride in the craft of design, figuring out constraints, building systems, nudging pixels, I also believe strongly in solving problems away from Figma.

I started with a very small project—a timeline feed/activity feed for the product I lead design for. Results were not all that bad.

What exactly is v0?

v0 is Vercel’s generative UI tool that turns plain text prompts into functional React components, using Tailwind CSS under the hood.

Think of it as ChatGPT, but instead of paragraphs, you get code blocks, and not just snippets, but entire interface layouts.

It’s fast, surprisingly competent, and most importantly, editable.

You prompt → it builds → you tweak → deploy.

(I’d take the deploy part with a pinch of salt)

No design file handoffs. No HTML-to-React rewrites. Just you and an AI prototyper.

A quick crash course

I’m using the free version right now, which gives you only 3 prompts before you have to wait till the next day for 3 more.

Quick plug: learning to write well, prompt well, give good direction to AI tools is a super important skill these days.

One of my highly liked article on prompting—

Let’s say you want to build a login page. Simple enough? Here’s how you’d do it.

Step 1 - Write your initial prompt

I’d suggest you be a little descriptive here. Don’t just write “Make a login page“, although, that works too. I’ve added a few more details like button color, style of the login page, etc.

And it is off to work…

Initial output—

Not bad. But we can make this better.

Step 2 - Add more details, enhance the design

I told v0 to make the card too wide. Let’s make that smaller. Let’s try to change the color of the primary button here, add a few other login methods as well.

Once it has made changes to the source code of the first version, it will come back to the Preview tab and show you the results.

Step 3 - Focused selection and editing

You can select a specific element on the Preview section and give v0 a specific change. Notice the arrow with lines around it towards the top right of the section.

I’d never do this if it killed me, but as an example, let’s make only the button fully rounded and taller.

Final result - Looks really cool, completely interactive

If you’re comfortable with code, please do explore the Code tab/section.

But since this is a GenAI prototyping tool, I’d nudge you to try prompting changes. Takes less time, and you can give a lot more information in one prompt.

Best uses I see for v0

The designer in me can’t get over how bad that button looks in the final screen, but let’s move on.

I’m not replacing my design process with v0; I will still take care of developer handoff. No, UX is not dead, UI design is not dead, nothing died. A new technology emerged, embracing it would be the best way to move forward.

Here are a few ways I intend to use it in:

1. Jump start UI work

Empty states, layouts, basic wireframes, error pages, 404 pages, etc., the stuff that needs to exist, but doesn’t need deep craft. I’d rather start here, discuss direction with my PMs and engineering counterparts and then use craft to make it better.

2. Unblock myself during ideation

I’ve already been using GPT to start brainstorming and get user stories/basic flows and ideas. Now, I can make something clickable. v0 can act like a collaborative partner for frontend automation.

3. Rapid test mockups with customers/testing groups

Sometimes, we’re in the middle of a deal negotiation with a customer. If they ask for something custom, and we take 2-4 weeks to produce an MVP, we will definitely lose the deal. I can just generate a few options, add their requests too, even live in front of them.

Where it falls short

Let’s be honest, v0 or Lovable or any other AI prototyping tool isn’t magic. It is good, fast and helpful. But, taste matters. You gotta know what to build and have a vision in order for the tool to do its job well.

• After a few prompts, all results start to look the same. Layouts are clean, but not inspiring and do not evoke emotion. (I don’t think they’re meant to, either)

• v0 doesn’t know your context, your market landscape, or your brand story. Which means, the output generated cannot reflect nuance

• Once you generate a UI, making iterative tweaks isn’t as smooth. Look at the search bar in the first image in this post—I told v0 to use the search icon from Material icons and it messed up the layout with it

• You can’t discuss ideas like you can with GPT or a human being. You can only dictate and get results

Some suggestions if you’re about to give it a shot

• Start with a UI component, get a feel of the app. A big UI project might not give you the confidence initially

• Treat prompts like design briefs—functional design, less UI design. Describe the intent, user goals, layout needs, etc.

• Write like a designer, think like a developer. Mention things like form validation, viewport height, dark or light mode, component states, and so on

• Use it to unblock yourself when you don’t get ideas. It is not a replacement for Figma in any way (at least not yet)

• Learn to prompt well. Maintain your own personal library of what works to reuse later

Final thoughts

I don’t think tools like v0 are about to replace designers. But I do think they are reshaping the starting point. And of course, they’re democratizing building apps. You don’t need a designer and a developer for simple projects anymore.

The real opportunity is in how you respond. Builders who treat these as collaborative tools will definitely pull ahead.

Be open. Give it a shot. Try the tool, break it a little, see where your gut feeling takes you.

Let me know in the comments if you want a detailed pro version tutorial.

If you liked this article, share it with your friends and colleagues. Show them the cool stuff you’re learning!

Share

Okay, this is going to be a long one.

Everyone has been talking about how AI will replace some jobs, kill certain other ones. Lot of scary stuff going on around.

Let’s talk about the way it rewards us techies.

This is definitely a personal observation and opinion, but if you want to stay relevant, useful, and in-demand for the next few years, there are 3 capabilities to master.

If your opinion on this topic differs from mine, I’d definitely love to hear about it.

Why this discussion matters

We are in a time where job titles are getting blurred, new tools and apps are being launched every week, and everyone’s trying to figure out where they fit it.

I mean, have you opened LinkedIn lately?

According to them, design is dead, UX is dead, engineering is dead, writing is dead. Not sure what’s survived!

But underneath all this noise, one thing is clear— AI isn’t replacing roles. It’s reshaping what value looks like.

The people who thrive won’t be the ones learning all the new tools (sure, there are advantages to doing that), but the ones who sharpen instincts that compound across tools.

I’m starting to rethink my belief that specialists will thrive over multiple decades. Generalists are taking over.

I’ve thought about this for a while and come up with 3 roles that might perform well—the Builder, the Architect, and the Integrator.

These are not predictions, they’re just a lens to spot what’s missing in your skillset, your team, or your product. And ideally, prepare for the future…

The taste gap—what AI can’t do

AI can write code, make videos, create images and interfaces, even mimic your tone.

But it still can’t tell the difference between bad, good and great.

It can be able to generate a hundred options, but you have to know which one to keep.

It can query everything on the internet—but you have to know what feels original.

It can automate workflows—but you have to know what’s actually worth automating.

That’s taste, and most people lack it (sounds like an unfair advantage to me).

And trust me, it is not just for designers. Engineers must have taste in architecture. Writers must have taste in rhythm, product folks must have taste in timing and bets.

You don’t need 10 years of experience to have taste. You need reps, reflection, and relentlessness.

Now, the 3 roles.

The Builder—master of craft

Idea → prototype → usable thing faster than most people can write a doc—that’s a Builder. It hasn’t shown up in org charts yet, but it’s the direction many high-performing designers, engineers, and indie-hackers are already moving toward.

Builders combine two instincts:

• The ability to make/build things fast

• The taste to make them good

Tools like Cursor, Framer, Webflow, Claude, Lovable, GPT act as multipliers here. Take rough ideas, shape them into something testable within days (or even hours sometimes).

Another name you could give them is craft-led executors.

Habits and traits for Builders

• Learn tools that let you prototype end-to-end (design+dev+AI)

• Practice building without perfect clarity—speed and clarity can coexist as much as is needed for version 1

• Develop taste through feedback, repetition, exposure, and study of great products

• Work on side projects that stretch your craft muscle

The Architect—master of structure

From user flows to system logic to roadmaps that don’t break—the Architect makes things make sense. This is a typical PM or senior engineer who outgrew their role and learned a ton of new things.

This role isn’t about control, it’s about clarity. Think across layers, how things connect, evolve, scale. AI helps simulate decisions, model outcomes, draft early thinking.

Judgement still remains human. Another name you could give them is clarity-first orchestrators.

Habits and traits for Architects

• Think in systems, not screens—map how parts relate before how they look

• Use tools like Whimsical, FigJam, Notion, GPT to visualize flows and strategy

• Develop the skill of narrative structure, learn to explain why something matters before how it works

• Practice simplifying messy problems into clean, explainable frameworks

The Integrator—master of leverage

Here, I’m talking about a supercharged domain-agnostic engineer. Integrators don’t reinvent the wheel—they connect the wheel, automate the driver, and build the road.

They see tools, APIs, agents, and data as blocks to be chained, not built from scratch. This role is the fastest emerging role right now.

Integrators answer with workflows, not ideas. They’re not just automating—they’re designing systems that scale quietly.

Another name for them—AI-native problem solvers.

Habits and traits for Integrators

• Learn how to chain AI, APIs, and logic tools to build real workflows

• Work backwards from outcomes—what do we want automated, and why?

• Build internal tools or scripts that reduce manual work across teams

• Follow emerging infra like agentic systems, vector DBs, and workflow orchestration tools

While you’re here, also check out—

You can be all three, eventually

You’re not expected to be all three, very few people are. But knowing these directions helps you grow with intention.

You might start with craft, and learn to build well. Then grow into structure, learning to make it work at scale. And eventually you might add leverage by knowing how to connect multiple systems together to produce an outcome.

There’s no need to panic, rush, or chase every new tool that drops.

The people who’ll do well in this new era aren’t the loudest or most technical. They’re ones with the highest adaptability.

Thanks for reading. If this piece gave you something to think about, I’d love for you to share it with a friend or teammate who’s figuring things out too.

Share

How great would it be to get promoted every year? New title, better comp, bigger scope, from junior to senior to lead—super fast. People say it is unrealistic, that you need to sit in a role long enough to grow into it.

Fair enough. But still—some ICs outgrow their roles in 2 years, others take 5. Sure, company size, company performance and timing matter. But that’s not the whole story.

What’s the real difference between the ones who move fast and the ones who don’t?

I’ve worked in a 3000-employee company, a 12-person startup, and now a 300-person company. I hope to be at a 30,000-person company some day too.

Across all these places, I’ve seen a common batch of the 1%. The 1% ICs who grow super fast. They’re not the smartest in the room, they’re not the loudest, they don’t work late or write the most lines of code.

They do things that don’t show up in performance reviews, but quietly shape how people see them. According to McKinsey, top performers in technical IC roles are up to 800% more productive than average performers—especially in complex environments.

That kind of growth comes from a different mindset, not just working hard. I’ve tired to compile a list of 5 traits you could also try and develop to be a top IC. This isn’t a polished exhaustive list. It is just a list of my observations.

If you’re a new reader here, thanks for giving me 5-10 mins out of your life. I hope this article can give you some value this week. Consider subscribing, the fish at my desk will love it 😊

Subscribe now

They protect their time like it’s sacred

One of my biggest achievements in the past 3 years—my calendar has largely stayed empty. It takes work to do that. But my gym time, learning time, and isolated design time are non-negotiables.

High-growth IC’s treat time like a finite resource, because it is!

You don’t need to join every sync and meeting. You definitely don’t have to say yes to every “quick catch-up.“ Most of them can be long messages or voice notes. (Also, a non-sponsored shoutout to Loom for making my life easier)

Creating time-boundaries within colleague interactions will let you make space for deep work. Cal Newport mentions it often in his bestseller Deep Work.

High performers do this because they know their real value doesn’t come from being available—it comes from delivering clarity, progress, and focus.

They confront misalignment instead of quietly adapting

Most people sense when something’s off—a confusing roadmap, a half-baked project, a decision that makes no sense—and just go with it. Not these ICs.

They ask questions.

They push back, respectfully, but firmly.

They call out gaps between what’s said and what’s actually happening.

Frankly, if you’re being yelled at or relegated because you’re calling out BS at a team or org level, they don’t deserve you. Find a place where you’re respected.

Quietly adapting feels safe in the moment. But it slows everyone down in the long run.

They invest in clarity even when no one asked them to

No one assigns clarity to these top-notch ICs. No one rewards it directly. But they do it anyway.

They rewrite vague tickets. They clean up docs that confuse everyone. They draw diagrams, write up next steps, make mind-maps—they bring order to chaos without being told to do so.

Why? Because they know teams move faster when things are clear. Not when everyone’s busy.

Clarity is definitely a performance multiplier at all levels. It stays invisible to most, but is like second nature to some people.

They make themselves obsolete at the right time

You definitely don’t have to be irreplaceable. But moving on to harder problems while someone else is enabled to deal with slightly simpler ones is a good thing for an IC.

The way to do that is to document your process, share what you learn, teach others how to do parts of your job and automate repeated steps.

To cling to a task or system limits your growth—even if you stop getting credit for creating it in the first place. Star ICs don’t dwell on their victories much, they move on to more challenging tasks.

The more you give away, the more room it creates for development.

They’re not afraid to be disliked—for the right reasons

I’ll be honest. I’m not the first person my team thinks of when planning a dinner. They assume I won’t be there and that I’m not a fun person to hang out in a club with. I’m fine with that—most of my high quality design work happens late evening and early mornings.

If you want to be a high-performing IC, you have to get comfortable with friction. Others might push for speed, you push for clarity. Others might conform to the manager’s words, you ask uncomfortable questions. Others focus on superficial recognitions, you focus on holding the bar high—on craft, on quality, on communication—even if it means you’re the villain at times.

Sometimes it frustrates people. In hindsight, everyone’s better for it.

It’s like that famous Robin Sharma book - The Leader Who Had No Title. You really have to lead before you actually get the title.

Lot of words, so here’s a summary

Phew, too many things to remember. Let me help you with 5 questions you can ask yourself this week (and as I write them, I know it will be more than 5) to start moving in the right direction—

1. Look at your calendar—what’s on there that protects your deep work time? If nothing, how many blocks will you book today for yourself?

2. What’s one thing in your work that just doesn’t make sense? Could you clarify it instead of adjusting to it?

3. Where’s one place in your work—tickets, doc, Slack—you could bring 10x more clarity?

4. Is there something you do manually that you could automate, document, or hand off to free up your time?

5. When’s the last time you challenged a low bar, even if it ruffled some feathers? Where can you do it this week?

More than any other trait, you have to start believing that you can do more, achieve more, and be more. Self belief can be an unfair advantage which goes beyond any trait or habit.

ICs who grow fast aren’t waiting for permission. They act like they’ve already earned the next level—and then reverse-engineer the actions needed today.

Not louder. Just sharper. More intentional.

Share this post with a friend you think can do better and let them know you believe in them.

Share

Don’t you just hate it when you can’t find a particular song, but you know how it sounds? You keep humming, but you just can’t find it. Well, that happened to me for this entire week searching for a particular episode of Lenny’s podcast.

Nevertheless, I have something super interesting to talk about. For the first time ever, I had a feeling that a particular business, has a fair revenue model.

I’m talking about Shopify. It wasn’t the first time I’d heard about how they work—but something clicked differently this time. I realized—Shopify only makes real money when its customers do.

Sure, they charge a basic subscription. But the real engine? It’s transaction fees.
They don’t just sell you software. They give you a platform, and then bet on your growth.

If your business sells more, they earn more.
If you don’t grow, neither do they.
That’s not just a billing model—it’s alignment.

Let’s get into it.

Loyalty is earned through alignment

Most platforms monetize usage.

You pay for seats, features, storage—even if your business isn’t growing. From a revenue standpoint, it's stable. But from a customer standpoint? It’s misaligned.

You're paying before you’ve succeeded. You're bearing all the risk.
And worst of all, there’s no real incentive for the platform to help you win.

Shopify flips that.

Its base plan is affordable, but the model scales only when the merchant scales. It’s not monetizing usage—it’s monetizing success. That’s not just fair. It’s smart.

It makes Shopify a stakeholder in your outcome, not just a tool in your stack.

Proof that this model works

In 2023, Shopify made over $7 billion in revenue. What’s even wilder? More than 70% of that came from merchant services—not subscriptions. That includes things like payments, shipping, capital, and apps—all built to help merchants sell more.

It’s proof that betting on your users’ growth works. You don’t need to squeeze value out of them—you grow with them.

That’s the beauty of this model:
It creates trust.
It builds loyalty.
It tells the customer, “We only win if you win.”

And maybe that’s the future.

More businesses should be designed not just to serve—but to scale with the people they serve. It’s more sustainable. More aligned. And in the long run, a whole lot stickier.

If you're building a business, here are 3 ways to move toward that mindset:

➔ Rethink your pricing. Charge less upfront. Let value grow with usage or outcomes

➔ Design for shared upside. Build tools that don’t just serve users—scale with them

➔ Measure success the way your customer does. Adopt their KPIs. When they win, make sure you feel it too

That’s what partnership looks like. That’s what makes me and many other consumers go “Wow, that’s fair. Here’s my money.“

If you’d like me to do a deep dive into Shopify’s business practices, drop a like.

I know I’ve been a little inconsistent lately, but I’m back. I’m reading quite a bit to bring you the best of tech, product, design and business.

If you’re a first time reader, hello! Thanks for reading. I’d love it if you considered subscribing. Makes my day, gives you something cool to read and think about every week.

Subscribe now

Every year, I make a few promises to myself. 2024 was especially about doing hard things—things that scare me a little, make me nervous, of which I know that the upside would be very high.

Started my newsletter, learnt newer things at work, read different kinds of books, ran a few long distance races.

This year is about embracing the zero.

I’m not the creator of this concept. I heard about it in Nick Bare’s podcast where he discusses marathon prep with his coach Jeff Cunningham. It gave me words to describe what I decided this year was going to be about.

Setback or possibility?

If your curious mind hasn’t yet arrived at a definition, here’s one—

Embracing the zero means seeing the start not as a setback, but as pure possibility. It’s understanding that the hardest part isn’t doing the work, it is letting yourself be a beginner.

Notice how I said “letting yourself be a beginner.“ Not just being one, but letting yourself be one. I believe there are 2 hurdles to this:

1. Fear—the invisible barrier

2. Ego—the thing that keeps you stuck

I’ll keep it short. It will be better if you gave it a deeper thought.

Fear

“I don’t want to look stupid“

“What if I fail?“

“I don’t know what I’m doing“

Sound familiar? That’s fear talking.

Not fear of the work, but fear of being bad at it. Fear of judgement. Fear of proving to yourself that you’re not as good as you hoped.

So you wait. Avoid starting. Convince yourself the timing isn’t right. But the truth? It’s never the right time. You just have to begin.

Ego

“I should be better than this“

“I don’t want to look like a beginner“

“This feels embarrassing“

That’s ego talking now.

Ego wants you to stay where you’re comfortable. It tells you that struggling means you’re not good enough. That if you can’t be great immediately, it’s not worth trying.

But ego is a liar. The best in the world were terrible at first. They just didn’t let it stop them.

Moving forward—the only way out

One of my favorite podcasters, Chris Williamson, speaks about all the things that are not doing the thing. Linking the post below and a small screenshot.

The only way out of your zone of fear or ego is action, the only way out is doing the thing.

You can think about starting, plan for it, wait until you feel ready—but none of it matters until you actually take action.

The work won’t get easier before you begin. The fear won’t disappear on its own. But, I can bet you that you will be proud of yourself for starting.

https://x.com/ChrisWillx/status/1664302375656357888

A little bit about adaptations

Have you ever gone to the gym consistently? Or practiced for a long distance race? If you haven’t, here’s what the prep phase looks like—

You start running on Day 1. At first, your body fights back. Your lungs burn, your legs feel heavy, your muscles cramp up every 200m. It feels impossible.

But then, something happens. You keep showing up. Your muscles adapt. Your lungs get stronger. The distance that once felt unbearable starts to feel routine.

That’s how progress works. Your mind works the same way. The more you embrace discomfort, the more resilient you become. The struggle never fully disappears—but you get better at carrying it.

Let’s start with 3 simple things

➔ Show up, even when it’s uncomfortable. Start small, stay consistent, and let progress build over time

➔ Detach from outcomes. Don’t chase perfection—focus on learning, adapting, and getting better

➔ Track small wins. Progress feels slow until you look back and see how far you’ve come—write it down, measure it, and keep going

Stop overthinking the start. Pick something, commit, and embrace the zero. The rest will take care of itself.

I’d love to hear your story. It might just inspire someone looking to start in the same domain. What are you committing to going forward?

Over the years, I’ve built some opinions and gained some experience. These opinions change based on the logic life/work presents me.

But one thought has never wavered—overbuilt products never win.

Or, put another way—simple products win, even in crowded markets.

Most product designers are executors. That means, they don’t own any product decisions. They own the implementation of the product vision using their skills.

If you are a designer reading this, the one big thing you can completely own is simplicity. I’d even to the extent of telling you to fight for simplicity.

Some famous examples

Look at the products that lost their way.

Myspace. Too many features, no clear focus. Facebook kept it simple—feed, friends, photos. Myspace drowned in custom layouts, autoplay music, flashy backgrounds, and clutter.

Evernote. The ultimate note-taking tool—tags, notebooks, AI, workflows, and a UI that got more and more cluttered every year. I loved Evernote at one point. Then Notion arrived with a simpler, cleaner, more flexible product. Almost everyone switched.

Skype. Once the go-to app for video calls. (Now this is slowly making me feel old…) Then Microsoft stuffed it with everything—chat, bots, integrations, ads. Zoom came along with one goal: effortless video calls.

Now look at the products that won.

Google Search. Other search engines crammed their homepages with news, stock tickers, and weather widgets. I mean, who even uses Bing or Yahoo? Google stayed simple—just a search bar. It became the default.

Superhuman. Not the first email app, not the one with most features. Just the one that made email feel fast.

Apple Notes. No fancy formatting, no endless customization. Just a blank page that syncs perfectly.

Simple products aren’t basic. They’re just easier to pick up, easier to use, easier to stick with.

From my experience

I have been designing a single product end-to-end for the past 2 years. I’ve tried to keep it as simple as possible. Almost every customer says the product is easier to adopt, and easier to learn how to use.

A simple product doesn’t mean simple technology. In fact, the simplest experiences are often powered by the most complex systems.

Google search looks like just a text box—but behind it is one of the most advanced AI-driven ranking systems ever built, parsing billions of web pages in milliseconds. The iPhone feels intuitive—but that simplicity is the result of relentless iteration, complex hardware-software integration, and years of optimizing tiny interactions.

Simplicity isn’t about stripping things down to the bare minimum.

It is about abstracting complexity so users don’t have to think about it. The best products don’t overwhelm you with options—they make the right decisions for you, in the background, without making you feel it.

How to make your products simpler

Elegance isn’t just about UI, it’s a full-stack decision spanning product, design, and engineering. Here are a few suggestions from various sources.

➔ Abstract complexity, enhance clarity. The most powerful systems work in the background—users should experience the benefits, not the mechanics

➔ Prioritize speed and responsiveness. A slow, clunky product isn’t simple, no matter how clean the UI is. Optimize performance from day one

➔ Reduce settings, increase intelligence. Smart defaults and automation remove friction—users shouldn’t have to tweak everything themselves

➔ Clarity beats decoration. Aesthetic isn’t the goal—interfaces should direct focus and make decisions obvious

➔ Fewer decisions, better outcomes. Too many choices create fatigue. Guide users toward the best action instead of making them think through every step

➔ Make onboarding invisible. Users should feel comfortable from the first interaction—progressive learning is better than overwhelming tutorials

➔ More features ≠ more value. Every feature must serve a core need—bloat makes products harder to use, not more useful

➔ Build for the 80%, refine for the rest. Solve for the majority first instead of stuffing in edge-case solutions too early

➔ Make simplicity a company-wide discipline. The easiest way to ship a complex product? Let simplicity slip at every stage. It has to be intentional

In no way am I an expert in making complex products seem simple. I’d love to hear your take on it as well. If you disagree with what I said, I’d like to hear that too.

Until the next week,

Happy building!

If you liked what you read, consider sharing it with your friends. It helps new readers find good content. It might also give you an idea or opinion for discussion with them.

Share

I’d love to connect with you 😃

I share ideas and thoughts on Twitter, LinkedIn and Substack Notes. I’d love to connect with you and talk about product, design or whatever interesting thoughts you have. Drop me a hi!

This is coming a little late, but I had this idea of doing monthly recaps in case you can’t find time to read all the articles. I’ll start doing these consistently every month.

If you’re a regular reader, consider this a quick go-to reference for all other articles from a month. Thanks for reading and supporting my newsletter/blog.

If you’re new here, consider subscribing. One article every week will land in your inbox free of charge, containing some ideas I’ve explored or something really cool I’ve read about. If you’re into product, design, business or tech as a whole, you won’t regret it.

Subscribe now

Okay, here’s the best of January—

10x Your Product Team's Output with Basecamp's Shape Up Method

➔ Most teams aren’t slow because of execution, but because of unclear priorities. Shape Up eliminates the chaos of backlogs, shifting teams from reactive planning to deliberate bets on high-impact work

➔ Fixed time, variable scope > Fixed scope, variable time. Instead of dragging projects out to meet unrealistic requirements, Shape Up forces teams to commit to a strict six-week cycle—what gets done, ships. What doesn’t, gets cut

➔ Ditch the backlog. Bet on what matters. Backlogs turn into graveyards of forgotten ideas. Shape Up replaces them with a betting system—only work that’s valuable and realistic gets funded for a cycle

➔ Small teams, full ownership, no handovers. Work moves faster when the same people shape, build, and ship. Traditional handoffs dilute accountability, but Shape Up’s model keeps builders in control from start to finish

➔ Scope creep isn’t a project killer if you plan for it. Instead of fighting last-minute ideas, Shape Up embraces flexibility—teams shape projects with built-in ‘rabbit holes’ so that when something unexpected comes up, they already know what to cut

Win Back 10 Hours a Week With This Simple Mindset Shift

➔ Most people lose hours every week by saying yes too often. Time isn’t taken from you—it’s given away. Protect it like your most valuable asset

➔ Meetings aren’t evil, but most of them are useless. If the agenda isn’t clear, if it could be a Slack message, if you’re not adding value—decline. Your time is better spent elsewhere

➔ Quick syncs are rarely quick. “Let’s catch up for 5 minutes” almost always turns into 30. If something isn’t urgent or high-impact, async tools like Loom and Notion work better

➔ Your calendar is a reflection of your priorities. If it’s filled with back-to-back meetings, scattered deep work, and little time for yourself, rethink what you’re allowing into your day

➔ Saying no isn’t selfish, it’s necessary. Every yes is a no to something else—your actual work, your focus, your energy. Be ruthless about what deserves your time

Founder's Playbook #01 - Paul Graham on Why Persistence Wins

➔ Persistence and obstinacy aren’t the same. One keeps you adapting and moving forward, the other keeps you stuck in place. Knowing the difference is everything

➔ Most people quit too early because progress isn’t visible. Success looks like slow, painful plateaus before the breakthrough. Those who stick around long enough are the ones who win

➔ Effort alone isn’t enough—you need to adjust. Being relentless is good, but only if you’re learning and evolving. If the strategy isn’t working, change the approach, not the goal

➔ The most successful founders outlast the hard parts. Airbnb was rejected by investors. Nvidia bet on GPUs when no one cared. The difference wasn’t luck—it was staying in the game longer than others

➔ Quitting isn’t always failure. Stubbornly pushing the wrong idea is just as bad as giving up too soon. The key is knowing when to pivot and when to push through

Three Steps to Finally Start (and Stick to) a Reading Habit

➔ Not reading isn’t a time problem, it’s a priority problem. If you treat reading like a hobby, it’ll always come second. If you treat it like eating or exercising, you’ll always make time for it

➔ Start small—just 10 minutes a day. No pressure, no speed goals, just a simple routine. Attach it to something you already do, like morning coffee or winding down before bed

➔ Pick books you actually enjoy, not ones you think you should read. Eat That Frog is great for non-fiction. The Count of Monte Cristo is a brilliant fiction starter. A boring book will kill the habit before it begins

➔ Keep your book where you can see it. The closer it is, the easier it is to reach for instead of your phone. Nightstand, desk, bag—make it effortless

➔ Reading isn’t about finishing books, it’s about making it part of your life. A few pages a day will add up faster than you think. Stay consistent, and it’ll become second nature

For February, I have some interesting topics prepared. As always, you’ll keep getting them every week right in your inbox.

I keep updating everything on LinkedIn and Twitter if you’d like to follow.

If you found something useful, share it with your friends. If you have any ideas for articles or topics you’d like to read more about, write them down in the comments. I will definitely try and write more of what you like :)

Share

It doesn’t matter if I’m reading about product, retention, customer success or company culture—they’ve figured it out.

And almost every time, the key takeaways is the same—customer obsession.

I know, I know…

We’ve heard customer obsession a little too much. Every company says they do it. Every founder says it at least 25 times a day.

But, what did Intuit actually do, over and over again, to turn “customer obsession” into one of the strongest competitive moats?

I’ll attempt to break it down. No boring stories, just a few key takeaways after a short story.

The Intuit Playbook in Action

It started with a phone book.

Back in the early days, Scott Cook (Intuit’s founder) wanted to understand what small-business owners actually needed. So he and his team picked up a physical phone book, called random businesses, and just listened.

No sales pitch. No product demo. Just question after question about what made managing money frustrating.

Most of the people spoke of not having an accountant and that they weren’t experts in money management. So Intuit built QuickBooks—not for accountants, but for people who hated accounting.

Took them 4 years to get 85% of the market share.

Then came TurboTax. Intuit focused on the everyday person who dreaded tax season. They designed it so anyone—without knowing anything about tax—could file their return with confidence, making it a default choice for millions.

They did it again with Mint—it was automatic, visual, and intuitive. Took budgeting from a chore to a habit.

There are many such products to talk about under Inuit’s belt.

A year ago, I realized Mailchimp is also under Intuit.

They seem to be predicting customer pain points, not just responding to them. They see friction before it becomes a complaint. They build solutions before users even realize they need them.

You see, this is customer obsession.

So, here’s what I see

➔ Most companies say they listen to customers. Intuit actually builds around what people struggle with, not just what they ask for

➔ The best products don’t just solve problems, they become habits. QuickBooks, TurboTax, Mint—once you start using them, they’re hard to leave

➔ Retention beats acquisition every time. While fintech startups fight for new users, Intuit makes sure businesses never want to switch

➔ Simplicity is underrated. Their products aren’t overloaded with features—they focus on what actually makes life easier for the user

➔ They don’t wait for disruption, they stay ahead of it. QuickBooks Online, AI-powered tax prep, the Mailchimp acquisition—moves made before the market forced them to react

➔ Intuit isn’t flashy, but that’s exactly why they win. They focus on making finance invisible, not exciting. And for customers, that’s exactly what they want

I’m sure it will be a good place to work at. You can’t keep winning without a good culture.

I’ll try and talk to someone senior at the company to get more insights for the next Intuit article.

As always, thanks for reading. Hope you have a great week ahead.

Also read

This wasn’t a vacation. It was work, a lot of work. Talking to people there gave me (and other designers) a lot to think about, a lot to learn and even more to unlearn.

Some of these lessons stuck with me. And they aren’t just for designers—they’re for anyone figuring out their path.

Non-sponsored shoutout -

The retreat was organized by Wolffkraft Design Studio.

They’re a bunch of cool people doing cool stuff. The founder, Mohit, is a good mentor friend and is deeply invested in the design community. Drop them a hello sometime!

Also, if you’re new here, consider subscribing :)

Lessons that stick - for Designers and beyond

1. Frame the problem so everyone understands

If people don’t get the problem, they won’t get the solution. Break it down, communicate it clearly, prototype early, and bring in different perspectives before you move ahead.

2. If you’re reliable, people will bet on you

The easiest way to earn trust—be predictable. When people know they can count on you, opportunities follow.

3. Act like the leader you want to be

Leadership isn’t given, it’s shown. Start making decisions, guiding discussions, and thinking beyond your role. The title comes later.

4. Find what truly drives you

External rewards won’t keep you going. The people who thrive are the ones who find something about their work that excites them everyday.

5. Sell your ideas with the right story

Great work doesn’t sell itself. Frame your design solution (or any idea) in a way that makes others want to buy in. Narratives make things stick.

6. Know your audience before you pitch

Speaking to business leaders? Use metrics. Talking to engineers? Get technical. You can’t convince people if they don’t understand the language you’re speaking.

7. Your work is never just yours

Everything you build is the result of many people’s efforts. Recognize that, communicate it, and share credit often.

8. Set new standards—always

If you’re comfortable, you’re plateauing. Keep raising the bar for yourself before someone else does.

9. Don’t optimize for your current role

You are replaceable. Understand that clearly. The goal isn’t to be perfect at what you do now, but to be prepared for what comes next.

10. There’s no single ‘right’ way to work

Stop obsessing over the perfect process. Focus on mastering your craft—skills will take you further than systems ever will.

Wasn’t just about thinking and reflecting. We had great espresso shots too!

If any of these hit home, take them, use them, and pass them on. And if you found this post useful, please do share it with someone who may need it.

Share

More to read here -

1. Three Steps to Finally Start (and Stick to) a Reading Habit

2. AI Prompt Playbook: The Only Guide You’ll Ever Need for Smarter Results

3. 10x Your Product Team's Output with Basecamp's Shape Up Method

Let’s see if you have the focus and patience to make it through this entire article—no images, no distractions, just words. Think of this as your first reading challenge.

In preparation to write this post, I was reading up on why reading matters. Ryan Holiday, one of my favorite writers on this subject, quotes Erasmus in a blog post:

“When I get a little money I buy books; and if any is left I buy food and clothes.”

Why would someone in the 1500’s say this? Why do most successful people recommend books as their go-to source of knowledge? Why do I spend half my savings on books? (Let’s not answer the last question, haha!)

Whenever I hear someone say they don’t have time to read, I don’t buy it. It’s rarely about time—it’s about priorities.

The real reason most people don’t find time to read is because they see it as a hobby. If you treat it as essential as eating or walking, you’ll make time for it, at any cost.

Nevertheless, if you genuinely don’t have time because you’re duty-bound by family or personal stuff, the pointers I present here should help you.

Dear reader, thanks a lot for reading this post. Grateful to have you here. As I strive to bring you more valuable content each week, I only ask of you to share my newsletter with friends and get them to subscribe - it would mean the world to me.

Share

Here’s how you start reading. Nothing fancy, no tricks—just three steps:

1. Read for just 10 minutes a day

2. Pick books you’ll actually enjoy

3. Make it impossible to ignore

That’s it. Start here, simple works.

If you just thought “10 minutes is too short, I can do 30”, you’re overestimating your will power.

If you could, you would have already.

Why simple steps work

The hardest part is getting started, not the habit itself. That is why simple works.

No overwhelming goals, no massive efforts, no overthinking. Just small, easy steps that fit into your day.

Reading for 10 minutes? That’s doable for everyone.

Picking a book you’re excited about? Easy.

Keeping it within reach? Takes zero effort.

“But I have so much work, I forget reading”

Habits stick when easy to remember. Only way to make sure you never forget is to tag your reading habit to something you already do every day—right after brushing your teeth, with your morning coffee, 10 minutes right after lunch, or before bed.

When it’s tied to an existing routine, it becomes automatic.

The simpler it feels, the harder it is to make excuses. And that’s how you turn “I want to read more“ into something you actually do.

For nerds like me, who want scientific backing

You know this already, but I’ll say it again—reading is a brilliant habit, it’s like workout for your brain.

Neuroscience shows that it improves cognitive function, enhances memory, and even rewires how we think.

• Strengthens neural pathways by engaging regions like the frontal lobe, temporal lobe, and hippocampus, improving language processing and memory retention

• Trains deep focus by requiring sustained attention, sharpening your ability to concentrate

• Enhances empathy by activating the brain’s default mode network, helping you understand others’ perspectives better

History backs this up too.

Leaders like Abraham Lincoln and Theodore Roosevelt devoured books, crediting them for their decision-making and creativity. Roosevelt even read a book a day during his presidency, proving that reading isn’t a luxury—it’s a tool for greatness.

If you’ve read this far, you can build a reading habit

Let’s start today.

• Read just for 10 minutes and pair it with something you already do, like your morning coffee

• Pick a book you’ll enjoy. My reading list page has a lot of suggestions, but try Eat That Frog (non-fiction) or The Adventures of Sherlock Holmes (fiction)

• Keep your book within reach. Bedside table, dining table, your desk—I like to keep one on my desk because that’s where I start and end my day

You don’t have to read a hundred books, or even a hundred pages. Just thinking about letting the habit grow slowly. Stick with it—you’ve already proven you can.

I’m reading The Creative Act next. I’d love to hear what you picked.

If you’re new here, welcome. This is the place where others like you read and grow together. Consider subscribing if you liked this post. Cheers!

If you can’t read anything else in this post, here’s a one-line summary of the entire thing:
Persistence is the ability to keep adapting and pushing forward, while obstinacy is simply refusing to change, even when it leads nowhere.

People of both of these traits - persistence and obstinacy - have a core underlying principle - “not giving up“. It is surprising how they could not be more different if you dig deeper into their internal structure.

The fine line between persistence and obstinacy

Let’s see two simple examples to explain the difference between the two.

Amazon’s early days were full of pivots - from selling books to becoming the “everything store“, many businesses/projects launched and failed.

Contrast with that Kodak, a company that refused to embrace the digital camera. Their obstinacy in clinging to film ultimately left them irrelevant in a world they helped create.

Netflix (pivoted from DVDs to an online catalogue) and BlackBerry (did not pivot when the world moved towards touchscreen phones) are equally juxtaposed.

When persistence goes wrong

You could keep pushing, but that can often lead you to stay stuck. Sometimes, you have to listen, understand and change a few things:

➔ When progress stalls, it’s easier to keep pushing than to admit something isn’t working

➔ Fear of failure makes us cling to the familiar, even when it’s clearly not the solution

➔ Lack of feedback or direction can lead to persistence in the wrong areas

Graham’s advice is clear:

Persistence is not about having unlimited grit or energy. It’s about accepting that growth is rarely linear.

Today’s entries for your Founder’s Playbook

Not giving up can shape your path - here’s how to make it work for you, not against you.

➔ Pause and reassess. When progress feels gridlocked, take a step back. Revisit your original goals and ask if your current actions are still aligned with where you want to go

➔ Experiment with new approaches. If one strategy isn’t working, try something different. Launch small tests or pilots to explore alternative solutions without risking too much. It’s okay to let go of ideas that aren’t working

➔ Ask better questions. Instead of pushing harder, focus on asking why something isn’t working. Understanding the root cause can reveal opportunities to pivot or adjust

➔ Get outside perspective. Talk to advisors, customers, or peers who aren’t involved in your day-to-day work. Fresh perspectives often uncover blind spots

➔ Focus on first principles. Break down the problem into its most basic elements. Simplifying complex issues helps you rebuild solutions with more clarity

There are two amazing thing I read in Graham’s essay (on which this post is based) titled The Right Kind of Stubbornness:

“Five distinct qualities — energy, imagination, resilience, good judgement, and focus on a goal — combine to produce a phenomenon that seems a bit like obstinacy in the sense that it causes you not to give up. But the way you don't give up is completely different. Instead of merely resisting change, you're driven toward a goal by energy and resilience, through paths discovered by imagination and optimized by judgement.”

“Energy and imagination make a wonderful combination. Each gets the best out of the other. Energy creates demand for the ideas produced by imagination, which thus produces more, and imagination gives energy somewhere to go”

What’s one area where you’ve been pushing forward but need to step back and reassess? Try a different strategy this week and see what changes.

Thanks for reading. If you find this post useful, I’d love it if you shared it with someone that might find it helpful. And consider subscribing if you haven’t already.

Until next week, cheers!

Share

This article isn’t related to any product or company. This is more about you.

In the past year, I’ve learned to manage time better after learning, applying, unlearning and reapplying concepts borrowed from several sources. (My most favorite source is the book Essentialism. A post will come out soon on it).

Let me paint you a familiar picture.

It is Friday, and your to-do list feels endless. Meetings, emails, and ad-hoc tasks fill your days, and yet at the end of the week, the bigs things - the work that actually moves the needle - remain untouched.

You sleep on Friday night, try to relax through Saturday, but Sunday gets over too fast, and Monday’s back again.

Studies show that we’re wired to focus on urgency over importance, defaulting to tasks that feel productive but actually aren’t. The result? You’re stuck in a cycle of busyness with little progress.

Here’s where the Pareto Principle is helpful - 80% of your desired results come from 20% of your effort.

It is not a hack. It is a mindset. A small fraction of your tasks drive real outcomes, rest is just noise.

A short personal story

My calendar at work averages 1 meeting a day. Sure, a lot of credit can be given to in-office work where the team can just come up to me and talk. But there are more small intentional judgement calls I make to keep the calendar that way.

• I don’t accept “quick syncs“ even if I’m not in another meeting. When I hear “Let’s catch up for 5 mins“, I know it is a 30-45 min call

• We use Slack at work. I hardly ever huddle also, when working from home. I insist on Loom videos or text messages

• If people from other teams want a meeting, they get one provided I’m actually needed for more than 30 mins. Usually, it is them talking for 25 mins, while I’m dragged in for my 5 min opinion

• I don’t work all day. I take breaks, I stop working for a few hours when most people are stuck in meetings. I workout in that time, complete any personal chores and read up for the next post I am writing at the time

All this might feel like I’m just being a bad teammate. My team has actually acclimatized with my routine and they work around it - only I can protect my time at then end of the day.

My team benefits too - they get more thoughtful design outcomes from me when I’m not distracted. Pareto Principle isn’t just about doing less - it’s about making what you do count.

Only 20% of my tasks create the outcomes I care about. Rest is either maintenance, buy-in or plain wasted.

Cutting The Noise - Here’s How To Do It

Slack can wait. Meetings can wait. Quick calls can wait.

Quality work shouldn’t wait.

You’re not unproductive - you’re spread too thin, trying to juggle everything at once.

Here’s how to clear the clutter, reclaim your time, and focus on the 20% that drives real results:

Cancel recurring low-value meetings

Unnecessary meetings are one of the biggest time drains. Research shows that workers spend an average of 31 hours a month in unproductive meetings. Most of these can be avoided.

• Review your recurring meetings. If they don’t lead to decisions or clear outcomes, cancel them

• Replace status updates or “quick-syncs“ with Loom videos or concise Slack messages. A 3-min video can save a 30-min meeting

• Before scheduling a meeting, ask - “Can this be solved with an email or Loom instead?”

Batch low-focus tasks

Emails, Slack messages, and small admin tasks interrupt your focus and eat up your day. Constant multitasking can reduce productivity up to 40%.

• Block two time slots daily for emails and Slack responses - one in the morning and one in the afternoon

• Set boundaries by muting notifications outside of these blocks. Important step - let your team know your schedule

• Group similar tasks together (e.g. Update hiring sheet, review portfolios) to minimize context switching

Say NO more often

Every time you say yes to something unimportant, you’re saying no to something meaningful. It’s uncomfortable, but essential.

• Politely decline tasks that don’t align with your priorities. Try - “I am focusing on something at the moment. Can I sit this one out?“

• Delegate tasks where possible. If someone else can handle it, let them

• Remember this - saying no isn’t selfish - it is how you protect the time and energy needed for high-value work

Focus on what matters and avoid the rest

Not everything deserves your attention. The more you focus on high-impact work, the more intentional you can be about ignoring the noise.

• Begin each day by identifying your top 1-2 priorities - the tasks that will make the biggest difference

• Balance this with a “Not-to-do“ list - anything that you consider noise

• Keep both lists visible to stay clear on what matters and where you’re wasting time.

My reading list page has a few book recommendations on time and project management:

BONUS: My Personal To-Do List Technique

After reading Eat That Frog by Brian Tracy, I tried the A,B,C,D task prioritization system, breaking tasks into A1, A2, and so on. It worked - but it was too elaborate and time-consuming for daily use.

So, I simplified it.

Instead of listing tasks vertically, I divide a page in my task notebook into 3 columns: A,B, C.

• A: 2-3 high impact tasks that must get done

• B: Important but less critical tasks

• C: Low-priority maintenance tasks that can wait

My goal is simple: complete all A tasks, at least 50% of B tasks, and let the rest of C roll into tomorrow guilt-free.

Seeing tasks grouped this way keeps me focused on priorities while giving me a clear picture of the day.

P.S. I love using Microsoft To-Do to have the A task list on my phone at all times.

This week, challenge yourself.

Audit your calendar, cancel one unnecessary meeting, and focus on just three tasks that truly matter. See how much more you can accomplish by doing less.

I hope this post gives you the much needed break in your day.

If you enjoy reading my content, the best thing you could do for me is to share the newsletter with your friends and family. I’ll be eternally grateful!

Share Beyond the Build

Does product building feel chaotic to you?

If you feel like your team is working harder than ever, but the results don’t match the effort, you aren’t alone. It is a pretty common sentiment within SaaS teams.

Designers are burned out chasing pixel-perfect tweaks for features users end up abandoning. Engineers are frustrated by sudden changes in scope. As a product manager or the founder, you’re stuck putting out fires instead of building something meaningful.

It’s not for lack of trying. It’s the process.

I read something very interesting while watching my own team going through similar times - Basecamp’s Shape Up philosophy.

In this post, I’ll break down three key ideas from Shape Up that have changed the way I approach problem solving as a designer. Think of these as a set of principles, not rules, to help your team focus on solving the right problems.

Rethinking How You Decide What To Build

Let’s take a step back.

Think about the last time your team delivered a project.

How much of that work felt truly meaningful? Was your team solving a clear problem?

Or did it feel like you were just trying to ship something - anything - to meet the sprint deadline or commitment to the customer?

Now imagine this.

It’s the start of a new project. You’ve got six weeks, not to deliver everything on a wish list, but to create the best version of what truly solves for user needs.

Your team isn’t overwhelmed by endless tasks or drowning in feedback loops. Instead, they’re laser-focused on solving a well-defined problem, knowing exactly what success looks like.

This is how Shape Up elevates the entire system.

Fixed time, flexible scope

The biggest problem with traditional Agile sprints? They create artificial pressure.

Teams are forced to cram everything in a short time frame, regardless of whether the scope makes sense. This leads to compromises - on quality, usability, or both.

Shape Up flips the script by anchoring the timeline while letting the scope adjust. In practice:

• Teams get a fixed six-week cycle - long enough to focus but short enough to maintain momentum

• Instead of jamming features into the cycle, the question becomes - What’s the most valuable work we can deliver in this time?

This subtle shift transforms how teams think. It’s not about finishing everything. It’s about shipping something meaningful.

What happens when scope is flexible?

• Teams prioritize impact over perfection

• They cut unnecessary features early, avoiding scope creep

• There’s room for iteration without sacrificing deadlines

I found a common theme here between Basecamp and Spotify -

Small teams are trusted with projects after shaping the problem to be solved.

Read more here:

Shaping work beforehand

Ever handed a project to your team only to realize halfway through that no one fully understood what was expected? That’s the result of vague tasks and unclear boundaries.

Shaping addresses this by focusing on preparation before execution.

It’s like sketching the blueprints before constructing a building. Without it, your team risks wandering into ambiguity or burning time on tasks that don’t matter.

What does it involve?

• Defining the problem: Get crystal clear about what you’re solving. Instead of “make the dashboard better“, reframe it as “reduce confusion on the analytics page“

• Setting boundaries: Identify what’s in the scope - and more importantly, what isn’t. It will fare well for the shaped up work to describe “this project doesn’t include changes to the API“

• Sketching ideas: This is rough sketching, not pixel-perfect UI designing. “People who read the pitch and look at the drawings without much context need to “get“ the idea“, says Ryan Singer in his book Shape Up.

At its core, shaping saves your team from drowning in uncertainty. It ensures they’re solving the right problem—not just any problem.

A side note - what not to build

Ryan, in his book about this framework, mentions very often about knowing what not to build.

Calling out what’s out of scope isn’t just a formality—it’s a guardrail that keeps teams focused and prevents wasted effort.

Here are simple guidelines you may use:

• If it doesn’t directly solve the defined problem, it’s out

• If it’s a nice-to-have that risks derailing the timeline, shelve it for later

• It if introduces complexity that outweighs value, skip it

Ruthlessly editing your shaped up scope will be the biggest contribution you make as a teammate.

Betting over backlogs

Here’s an annoying question - how much of your back log actually gets done?

For most teams, the answer is not much.

Shape Up goes against convention to say, scrap the backlog.

Instead of keeping a running list of tasks, Basecamp uses a betting table. Every six weeks, decision-makers choose a small number of projects to “bet” the team’s time on. The rest? It’s shelved—intentionally ignored for now.

How does betting change everything?

• Focus on the highest impact work: Betting forces hard choices. What matters most is the cycle, value to the customer within the cycle and constrained use of resources

• Alignment across the team: Everyone knows the priorities because there’s no noise from an endless backlog

• Better use of resources: Teams aren’t spread thin chasing too many projects

Interesting Techniques From Shape Up

1. Breadboarding

Think of breadboarding as a way to sketch functionality without getting bogged down in design details. It’s a method for visually mapping out the flow of a feature or product—what happens, where it happens, and in what sequence.

Imagine designing a checkout flow. A breadboard might show -

1. User adds an item to the cart

2. User goes to the cart

3. Proceeds to payment

4. Completes payment and lands on confirmation screen

No colors, no buttons - just the core steps to align on functionality

2. Embedded sketches

These are quick, low-fidelity drawings embedded in written explanations to clarify ideas. Ryan calls them fat marker sketches.

Instead of saying “Add a search bar to the header”, a sketch shows the bar’s placement above the navigation menu.

A rough rectangle with a few labels is often enough to spark meaningful discussions.

3. Pitches

Pitches are concise documents outlining the problem, solution, scope, and risks—everything a team needs to bet on the project confidently.

A sample pitch from Basecamp:

Key Takeaways - Ideas You Can Try Today

You don’t need the entire Shape Up framework to see its benefits.

In fact, I had a conversation today with the PM I work with about this. He said it depends on the maturity of the team building the product. So, this framework may very well not work for you. Nevertheless, it is worth it to try a few things.

Try a six-week cycle

Set a fixed timeline for your next project, but allow the scope to remain flexible. Instead of squeezing everything in, ask -

“What’s the best version we can deliver in six weeks?

This ensures your team focuses on quality over quantity, reducing burnout and rework.

Shape your next problem well

Before jumping into execution, take time to shape the work. It is worth it.

Define the problem clearly, set boundaries and sketch a low-fidelity solution to give your team direction without micromanaging.

Rethink how you approach your backlog

Experiment with a betting table for the next cycle.

Pick 2 or 3 high-priority projects to focus on. Archive everything else - yes, everything. Even bug fixes. (Unless bugs are so bad that the product stops functioning, they can be put off for a bug-fixing cycle of itself).

This forces you to make touch decisions and ensures your team’s energy goes into work that truly matters.

Build with clarity, not chaos.

What could your team achieve if you gave them six weeks of clarity? The answer and surrounding reflections might surprise you. I’m eager to hear from you about this.

Okay, we’re done here. How was this post? Let me know in the comments.

I have a question for you. Help me serve you posts at the time you like most, so that you can read them and find value without feeling overwhelmed with content.

After spending a year experimenting with chat-based AI, I’ve learned that the difference between an average response and an accurate, relevant one often comes down to how you ask. AI is only as good as the prompts you give it.

AI can understand plain English, but if you don’t know what you want in detail, it’s as helpful as that one guy in meetings who says, “No updates.”

In this guide, I’m sharing everything I’ve learned about writing better prompts - guidelines and tips - to help you get the most out of every interaction.

If you’re short on time, please feel free to skip straight to the Action section for practical takeaways you can use right away.

Principles - Building Blocks of Better AI Prompts

You don’t need to be an AI expert to craft effective prompts and get great results. Just tailoring your inputs to get what you want helps.

The many faces of AI prompts

For those who prefer less complexity in life, here are the two main types of prompts:

1. Instructional - Direct and goal-oriented, like asking AI to summarize, rewrite, or explain something

2. Conversational - Designed to mimic a dialog, useful for brainstorming or exploring ideas

For the more curious minds, AI prompting gets even more nuanced with these advanced techniques:

Zero-shot prompts

• The AI performs a task without prior context or examples, solely depending on its training data

• Why it’s useful - saves time when tasks are simple and well-defined

“Translate this sentence into Spanish”

One-shot or few-shot prompts

• The AI is given one or more examples to guide its response and establish a pattern

• Why it’s useful - helps steer AI towards the desired output tone or style; great for tasks requiring specific formats or consistency

“Here are three movie reviews: [Movie 1 review], [Movie 2 review], [Movie 3 review]”. Based on the examples given, write a review for the movie “Gladiator 2“

Chain-of-thought prompts

• Encourages the AI to think step-by-step by explicitly stating how to approach a problem

• Why it’s useful - improves the AI’s reasoning for complex tasks

“Explain how to calculate compound interest step by step“

You don’t need to remember these names, but it helps to know that combining these techniques can help you tailor prompts to fit almost any situation. The key is mostly always to give specific instructions.

Core guidelines for smart prompt writing

A well crafted prompt is clear, contextual, and intentional.

1. Clarity is everything

AI thrives on clarity. Ambiguous prompts lead to vague or incorrect outputs.

• Be direct and avoid filler words or long-winded instructions

• Use plain language, don’t overcomplicate with jargon unless necessary

2. Always provide context

• Set the scene, describe the situation, audience, or purpose of the task

• Reference details, and use specific details when possible

3. Use constraints to your advantage

• Specify length, tone or format

• Add boundaries to guide the AI on what to avoid or emphasize

4. Break down complex tasks

• AI works best with clear, single-step instructions. For multi-step tasks, break them into smaller prompts.

5. Iteration is key

You don’t have to settle for the first response. Prompts are not a one-and-done task - you can tweak them to get closer to what you need.

Start simple, see how the AI responds, and refine from there. You can go one step further by treating AI interactions as a dialogue.

6. Be role-specific

AI performs better when you assign it a role or persona. Saying, “You are a teacher,” or “You are a startup advisor,” gives the model a framework to shape its response.

You can go one step ahead and combine roles with tasks.

The more precise the role, the more tailored and relevant the output.

7. Test and track your prompts

If you want consistent, high-quality results, don’t just use a prompt once—test it and keep track of what works. Push the AI to its limits by exploring edge cases, like asking it to explain a concept to a beginner or reframe it for an expert.

This helps you identify gaps and refine your prompts for clarity and adaptability.

You can go one step further by building a prompt library. Document effective prompts for recurring tasks, whether it's writing emails, brainstorming ideas, or coding assistance. Over time, you’ll have a reliable toolkit of prompts that deliver great results every time.

What to avoid

Ambiguity is your biggest enemy when it comes to AI prompts. If your instructions are vague, you’ll end up with vague responses.

The more direction you provide, the better the results.

Another common mistake is overloading the prompt with too many instructions. AI works best when tasks are broken into smaller, manageable steps.

Finally, don’t expect the AI to perform flawlessly in logic-heavy or niche areas without guidance. Recognizing these limitations and providing examples can bridge the gap.

Also read -

Perspectives - My Learnings From a Year of Prompting AI

I’m going to keep this section short for this post. I don’t want to dilute focus from the actual guidelines. But here are a few things I’ve learned over the past year:

• It’s like having a brainstorming partner who’s quick but sometimes wrong

• As a designer, I often start by explaining problems, get initial ideas from AI, and then refine them using my own expertise

• The answers aren’t always accurate, and when they’re off, I trust my instincts instead

• To some, this might feel like cheating—but for me, it’s just accelerating a process I’d do anyway, saving time and effort

• GPT is amazing for generating alternatives—headings, button labels, modal copy. A huge time-saver for repetitive creative tasks

• Writing detailed prompts can feel time-consuming, but the results usually justify the effort by speeding up the ideation phase

• I’ve even stored reusable prompts for recurring tasks, especially long problem-space descriptions that save me from retyping

• I’ve tried several tools—Claude, Gemini, Perplexity, Co-pilot—but GPT remains my favorite for its versatility and speed. Claude’s nuanced answers are intriguing, though, and I might spend more time exploring others

The most important lesson I’ve learned about AI prompting, though, is that negatives matter. Think of AI suggestions/answers as “avoiding the wrong targets so it eventually hits the right target” rather than “this is exactly the target”.

Action - Your Playbook for Writing Smarter Prompts

• Be clear and specific

  • Say exactly what you need. Avoid vague instructions

    Instead of “Explain recursion,” try “Explain recursion in Python with a beginner-friendly example”

• Provide context

  • Set the scene—who, what, and why

    “You are a teacher creating a lesson plan for high school students on climate change”

• Add constraints

  • Define length, tone, or format to shape the response

    “Write a 150-word summary in a formal tone”

• Break down tasks

  • Divide complex tasks into smaller steps for better results

    “List the steps to write a blog post outline. Then expand on step one”

• Iterate and refine

  • Adjust your prompt if the first response isn’t right

    “Rewrite this response with a more conversational tone”

• Assign roles

  • Guide AI’s perspective by giving it a persona

    “You are a marketing expert crafting a social media strategy”

• Use examples

  • Show AI what you expect with a sample

    “Here’s a sample review. Now write one for this movie: [Movie name]”

• Document what works

  • Save prompts that deliver great results to reuse later

• Test edge cases

  • Ask AI to simplify or explain ideas to different audiences

    “Explain blockchain to a 12-year-old”

• Experiment fearlessly

  • AI thrives on iteration. Try new approaches, learn, and adapt

There’s no single way to write the perfect prompt. Experiment with different approaches, combine techniques, and adapt them to the task at hand. What works for brainstorming may not work for troubleshooting, and that’s okay.

Think of these guidelines as the building blocks rather than rules. Mix, match, and iterate to find what suits your style and needs. With a little practice, you’ll find your rhythm and unlock better, faster results.

When I started working and earning my own money, the first app I paid for was Spotify. They had all the songs I wanted to listen to, and surprisingly, the ads were annoying enough to make me want to pay for the premium version. But, they’ve earned my trust since then.

By 2014, Spotify faced an existential challenge - Apple and Amazon were gearing up to dominate streaming and suddenly, “millions of songs in an app” wasn’t differentiating enough. It became the base line.

Stakes were clear - innovate or be crushed by popular giants. Their old waterfall approach to product development was too slow, rigid and too risky to let them innovate fast.

It wasn’t just about moving faster—it was about building smarter, scaling better, and staying ahead in one of the most competitive markets in tech.

Before you read further…

I will divide all my articles into 3 digestible sections:

1. Principles - the knowledge around the topic

2. Perspectives - my opinions and thoughts around the topic

3. Action - key takeaways for you, the reader, to try out

I will try to keep the sections as concise as possible. If you would like me to add more high level sections or if you have any suggestions, please feel free to comment on this post.

Principles - How Do You Take Impactful Product Decisions?

Spotify’s success didn’t come from a single brilliant feature. It came from a set of guiding principles that shaped how they decided what to build, how to build it, and how to manage risk.

Joakim Sundén, an early coach at Spotify, defines three main dimensions of the Spotify Product Model:

• Product strategy - how the company decides the most important problems to solve

• Product discovery - how they solve the problems and discover solutions worth investing resources into

• Product delivery - how they build, test and deliver those solutions to customers

You’ll see all 3 dimensions come into play once we discuss the actual prioritization framework.

Build autonomy and trust

The approach we’re discussing is rooted in autonomy. If you’re a leader who isn’t in favour of letting teams take decisions without involvement of senior management, you might want to rethink your management style.

Teams are given the freedom to make decisions, take risks, and own their outcomes - without waiting on endless approvals. This allows for faster innovation and response to user needs.

• Independent teams (squads and tribes) operate with full ownership, supported by a lightweight structure (tribes, chapters, and guilds) to foster collaboration and alignment

• Teams are trusted to deliver without heavy oversight, creating a culture of self-accountability

Case Study - Spotify’s Discover Weekly

When Spotify set out to create Discover Weekly, the goal was simple: make discovering music effortless for “lean-back” listeners—those who wanted great playlists without the hassle of curating them.

To achieve this, Spotify took a data-driven and user-focused approach:

• Behavioral insights: They analyzed billions of user-generated playlists to identify patterns in song groupings. This allowed them to understand the nuances of personal music preferences

• Collaborative filtering: By using machine learning, Spotify identified songs that listeners with similar tastes grouped together, creating a personalized playlist for each user

• Small-scale testing: The feature was rolled out to a limited audience, enabling the team to tweak the algorithms based on real-world feedback

The result? Discover Weekly became an instant hit. Within its first year, Spotify users streamed over 5 billion tracks through the feature.

Why it worked:

• A focused team worked independently to solve a clear user problem

• Early testing ensured they could refine the feature before scaling

While the feature relied on machine learning, it was grounded in deep understanding of user behaviour

Manage risk systematically

Spotify’s innovation isn’t just fast - it is deliberate. Every feature they build passes through a structured framework to reduce risk - Think it, Build it, Ship it, Tweak it - and it is central to how they deliver impactful features consistently.

Here’s how it works:

1. Think it: Prototypes are created to test ideas quickly and cheaply. The focus here is on reducing value risk—making sure the idea solves a real user problem

2. Build it: The leanest possible version (MVP) is developed to validate feasibility and usability

3. Ship it: Features are rolled out incrementally, gathering real-world user feedback

4. Tweak it: Data from the rollout is used to refine and improve the feature post-launch

Why this matters:

• Prototyping ensures only strong ideas make it to development, saving time and resources

• Incremental rollouts allow Spotify to learn from actual users instead of relying on assumptions

• Instead of treating the launch as the final line, Spotify uses it as the starting point for refinement

For example, when building Discover Weekly, the team didn’t dive straight into a full release. They used early prototypes to test their recommendation algorithms with small groups of users, ensuring the feature resonated before scaling it to millions.

Prioritize continuous delivery

The smartest teams don’t rush to build—they validate, test, and adapt every step of the way. By breaking product development into manageable phases, you can reduce risk and make better decisions, without overwhelming the user.

Speed isn’t just about working faster - it’s also about delivering more frequently. Continuous delivery allows teams to ship small, iterative changes rather than waiting for massive releases.

Why it works:

• Each release provides data to refine features and reduce risk

• Teams can experiment without derailing larger projects

• Incremental updates keep the product fresh and aligned with user needs

This approach drives measurable results:

• Spotify deploys code multiple times a day, allowing for rapid experimentation

• Incremental updates helped Spotify scale to 500 million users worldwide while consistently improving core engagement metrics like session length and retention. As of second quarter of 2024, the active user count is at 626 million

Perspectives - I’m Pitching This to My Team on Monday

What I love about this approach

I learnt something new while researching for this article - Product Risk. I’d heard of it, but never knew how it factored into product decision-making.

Since they release fast and test with a smaller user base while gradually rolling out the feature to everyone, they reduce that risk by several folds. Imagine what would happen if you took months to build something only to face reality when users don’t want that feature or new product.

I am definitely pitching this to my team this week.

The phased approach (“Think it, Build it, Ship it, Tweak it”) ensures fewer resources are wasted on unproven ideas. Multiple teams can come up with ideas for new products/features (in smaller teams, it could be multiple ideas from the same team). Subjective decisions are taken and you remain with only a few ideas that show merit. Not a single line of code needs to be written before the Build It phase.

I’ve known many teams falling into classic the trap of overbuilding features nobody needs.

I see a few challenges in adoption

Scaling autonomously is hard

• Not every company has the resources to replicate Spotify’s agile squads and frameworks

• Without strong leadership and alignment, autonomy can lead to siloed efforts or duplicative work

Intangibility of the “Think it” stage

• The “Think it” phase heavily relies on intuition and team creativity, which can make decisions subjective. Let’s be honest - not everyone is mature enough to take good subjective decisions

• For smaller teams without Spotify’s data infrastructure, validating ideas at this stage can feel more like guesswork

Continuous delivery requires discipline

• You know very well how adept your team is, when it comes to delivering continuously without burning themselves out

• For teams new to this model, shipping fast might lead to shipping sloppy work

Spotify’s approach is undeniably effective, but the real lesson isn’t to copy their model outright. It’s to adapt their principles—autonomy, risk reduction, and iteration—to fit your team’s size, culture, and goals.

Key Takeaways - Putting It In Action

Empower Teams Through Autonomy

• Give teams ownership of specific areas to innovate faster and make decisions independently

• Build trust by focusing on outcomes, not micromanaging every step

Reduce Risk at Every Stage

• Test ideas early with small prototypes to validate their value before investing heavily

• Use phased development like “Think it, Build it, Ship it, Tweak it” to adapt as you go

Deliver and Improve Continuously

• Ship small updates frequently to gather real-world feedback and keep improving

• Invest in the right infrastructure to support rapid, high-quality releases

Align Teams With Clear Goals

• Set outcome-driven goals so teams stay focused and aligned without rigid control

• Foster collaboration by balancing independence with lightweight alignment mechanisms

Build for Experimentation and Impact

• Start small, fail fast, and treat every experiment as a learning opportunity

• Focus on solving real user problems, not just building flashy features

The path to momentum lies in staying curious, experimenting boldly, and refining relentlessly. As builders, the challenge isn’t to copy Spotify’s methods but to find the principles that resonate and adapt them to your unique context.

How do you decide what to build next? I’d love to hear from you in the comments.

Most people are able to crack the idea, but success lies in the execution.

This newsletter is about the second phase - the one that doesn’t get enough attention. We celebrate launches, MVPs, and big product reveals. But the truth is, the hardest (and at times boring) work begins after the product ships - growth, retention, distribution, and creating ecosystems that make products indispensable.

I started this newsletter because of what I’ve been experiencing firsthand. As a product designer in a 0-1 team, I design everything a user sees on the screen - but because we’re a small team, we’ve all taken up additional tasks.

I’ve written content for years, but writing content for a 0-1 SaaS product is a whole new ballgame. This opened my eyes to an important truth:

The saying “If you build it, they’ll come“ is a big myth.

What separates the good from the great isn’t the build itself—it’s what comes next. That’s the question I want to explore here on Beyond the Build.

What Stripe teaches us about hustling beyond the build

When Stripe launched in 2010, its product was simple: a set of APIs that made it easy for developers to integrate payments into their apps. It was a fantastic product—elegantly designed, developer-friendly, and filling a massive gap in the market. But the Collison brothers knew that building the API wasn’t enough.

Stripe’s real success came from what they built around their product. They didn’t just target developers; they empowered them. Stripe invested in exceptional documentation, built out libraries and SDKs for every major programming language, and created partnerships with key platforms to expand their reach.

Over time, this approach turned Stripe into more than just a payments processor. It became an ecosystem. Developers didn’t just integrate Stripe—they advocated for it, recommended it, and in many cases, built businesses on top of it.

The lesson here is clear:

Even the most beautifully designed product won’t thrive unless it’s supported by distribution, education and partnerships.

Stripe didn’t stop at building a product; they worked relentlessly to make it the go-to solution for developers worldwide.

Solving problems beyond the product - the Intuit story

Intuit’s early success with products like TurboTax and QuickBooks didn’t just come from great design or usability—it came from understanding the entire ecosystem of small businesses and individuals they served.

For example, QuickBooks wasn’t just accounting software; it became the backbone for small businesses to manage payroll, taxes, and invoicing. Intuit focused heavily on building partnerships with accountants and financial institutions, creating an ecosystem where their product wasn’t just useful—it was indispensable.

The takeaway:

Intuit didn’t stop at solving one problem. They looked beyond the product to address the broader needs of their users, creating trust and loyalty that fueled their long-term growth.

The journey ahead

This newsletter is my way of bringing you along on that journey. I’m not here as a subject matter expert; I’m here as a curator, exploring the stories, strategies, and lessons that can help all of us think bigger about what comes after we’ve built something great.

Whether you’re a founder, a PM, a designer like me, or someone just curious about what separates good from great in tech, I hope Beyond the Build can be a place where you find ideas that inspire action.

Coming up next

Some pieces I have planned for the initial posts here:

• How Spotify decides what to build next: A behind-the-scenes look at how Spotify balances creativity and data to make product decisions

• Why Discord wins at community building: Lessons from the platform that turned online groups into thriving communities

and a lot more…

I hope you’ll stick around - there’s a lot we’ll explore together.

Happy building,

Som