Skip to content

How I do product roasts

Product roasts are the best way to enhance one's sensibility around building better products. It's called a "roast" because it often involves a no-holds-barred, brutally honest critique of the product's features, design, user experience, and overall value proposition.

In the spirit of 'everything is a remix', I've liberally forked, remixed and adapted a set of questions from industry leaders like Manas Saloi and Julie Zhou, to create my own tailored questionnaire for a product roast.

I run this through a new product or even a feature I would like to dig deeper into.

Strategy, Distribution and Market

      • If I was the PM for a product, how would I grow it?
      • What is the GTM of this product?
      • How big is this market?
      • Is the app a leader in this category?
      • Where does the product fit into the larger ecosystem of other companies/competitors? Where are they in this landscape?

Understanding the company and the larger context

      • What are the other products which the company creates? How does this product fit into the larger ecosystem?
      • What's the culture and DNA of the brand?
      • What is the tone and voice of their brand? Any hints being dropped from their company blogs?
      • Any news from seekingalpha, perplexity, techcrunch, crunchbase on the company status
      • what is the vision the executives from the company are pitching in global platforms/podcasts/round-tables etc?

Playstore

      • Is the name unique? is it memorable?
      • What is written in the About section? Is it too generic? Do they talk about the value prop in terms of JTBD?
      • How do the screenshots look like?
      • What are the metrics shown on the playstore page?
      • Do I see it running ads on its competitor pages?
      • What has been their approach for the description? Is it just a bunch of keyword stuffing? Written description using reviews of their users to show social proof?
      • How is the page different from its competitors?

Positioning

      • What do I think about its positioning? Has the positioning been consistent across other touchpoints?
      • Is there a crisp and consistent description of the product across their playstore page, app?
      • What is A, B and C, but not D for this product? What are the things they say they do, and the things they say they don't? And the things they say they do, but don't?

Onboarding

      • How frictionless is the onboarding process? Any identifiable barriers?
      • Is signup mandatory?
      • Can you skip the onboarding process?
      • What is asked in the onboarding process?
      • How quickly can you get to the meat of the product? Get gratification by completing the task I hired for? Measure both by the number of steps as well as the time taken
      • What is the developer optimising for in the signup flow?
      • What are the decisions in the onboarding that might affect the FTUE?
      • Are they talking about features or jobs?

First Time User Experience

      • How does the app feel? What emotions does it raise?
      • Is the FTUE overwhelming? Does it meet my expectations?
      • If I have to describe this app to others, how will I do that in less than 8 words? Will I use the same thing highlighted by the product team on the playstore page/app?
      • Is the experience a straight line?
      • What is absurd/supernormal about it?
      • If I was the PM designing this FTUE, what data would I collect to personalise the experience?
      • What are the hypothesis I have that I would test as a PM?

Jobs to be done

      • What are the main jobs a user might have been hired this product for?
      • What does the JTBD force diagram look like for this app?

Defensibility

      • What is the moat?
      • How is the app increasing the switching cost?
      • How is it decreasing switching cost if I am thinking of switching over from other apps?

Building trust and reliability

      • What are the trust indicators in the product?
      • How is the app reducing customer anxiety?
      • Is there any social proof?
      • How does the user know it is a legit business?

Product and Design

      • What are the interactions I like?
      • What do I hate?
      • Do I like the information architecture?
      • What are the things I can copy in my own products?
      • Is there some interactions, some visual elements which do not map to the convention? Any that follow industry standards that other apps don't?
      • Does the product design align with the frameworks I have learned over the years? Where does it deviate from the norm?
      • Now that i have used the product, what are the metrics I think the PM should be measuring?
      • What do I think the north star of the product is?
      • What are the experiments I would run?
      • Does the app experience tie back to what was promised in the playstore?

The Modern Startup Stack: SvelteJS + Ruby on Rails

Choosing a web framework is like choosing your first pokémon.

I didn't want to succumb to the 'new hotness' problem with the myriad of JS frameworks to choose from (Angular, Vue, React, Solid). I wanted something that i can choose and stick to for atleast a decade. So I resorted to a Rails monolith for building apps (but with a slight twist)

To start with, I chose Ruby on Rails. It's a Lindy-compatible web framework that's mature, stable, and well documented. It's been around for over 20 years, built on a language that's been around for over 30 years.

I was prompted to take the Ruby on Rails red pill through a recent talk by Irina Nazarova for the RailsConf keynote.

Although Ruby on Rails was touted as a great framework for a solo developer, it still missed the reactive-component jazz. React made complex UI possible. In fact, the #1 request from young Rails startups was the need for proper React support in the Rails community.

React and other reactive frameworks excel at building highly interactive user interfaces (UIs). Not just that, there are some killer libraries which I could only find in the react ecosystem such as framer-motion, svelte-motion etc

Evil Martians: Rails Startup Stack
Evil Martians recommend a selection of services, gems, resources, and materials to build and grow fast-paced businesses with Ruby on Rails.

Surprisingly, there was a solution to bridge the gap between Rails and React. Inertia.js served as that bridge, seamlessly integrating traditional Rails templates with reactive frameworks like React, Vue, and Svelte.

In fact 90% of the UI can be done on Rails and Hotwire. And the reactive frameworks could be used to selectively sprinkle on top of Rails for more complex UI requirements. What sort of reactive framework should I choose then? React, Vue, Svelte, Angular?

My primary considerations were code simplicity, readability, and community support. Performance mattered, but it wasn't the sole determinant. Google Trends provided a snapshot of each framework's popularity and adoption rates, helping me gauge their standing in the developer community.

React continues to capture the lion's share of attention, whereas Svelte remains obscure, hippie and unnoticed

Svelte tipped the fence for me, owing to their focus on simplicity, more than performance. It's just like React or Vue, but it's a compiler.

Svelte generates highly optimized JavaScript code, resulting in faster load times and a smaller bundle size. With Svelte, you only ship the code that your app needs, reducing the initial load time significantly.

Svelte was like Rails for the front end (low barrier of entry, sensible defaults etc) and I wanted to get the two working together. I also wanted to use Inertia which is a sort of 'glue' between your front and backend that allows you to use standard controllers without having to write an API.

Svelte's Tutorial Website is top tier

The way that Svelte has structured their tutorial website and documentation is top tier. When you go to their tutorial page it greets you with some instructions on the left and an IDE on the right. I liked the attention to detail in the tutorials. They even didn't allow visitors to copy-paste code onto the IDE on the right as they wanted visitors to manually type down the code for better retention. I just fell in love with this tutorial page :)

Their tutorial series consists of 4 parts with each having different lessons all separated by categories.

React also has a tutorial on their website. In no way is that tutorial better than Svelte’s. React has structured their tutorial through documentation rather than an interactive layout like Svelte’s.

React's website for teaching
React's tutorials are more structured around documentation whereas Svelte is structured around building projects

This may just be personal preference, but I loved how thought-through the learning process for Svelte is. It's so beginner friendly.

You want to make a component that adds two numbers together?

<script>
let a = 0, b = 0;
</script>

<input type="number" bind:value={a} />
<input type="number" bind:value={b} />
<p>{a + b}</p>

Now switch to React:

import { useState } from 'react';

export default () => {
	const [a, setA] = useState(0);
	const [b, setB] = useState(0);

	return (
		<input type="number" value={a} onChange={(e) => setA(e.target.value)} />
		<input type="number" value={a} onChange={(e) => setB(e.target.value)} />
		<p>{parseInt(a) + parseInt(b)}</p>
	)
}

Goes without saying that the language of Svelte is highly readable.

Some hard fought lessons from Tony Dinh here. You just pick a framework and stick to it. No back and forth!

Now that I've locked in on my stack for the next decade, I'll touch a bit upon the setup I use to build Rails+Svelte apps:

Inertia Rails Integration

rails new rails-inertia-svelte

Add the relevant gems:

bundle add inertia_rails
bundle add vite_rails

Install vite:

bundle exec vite install

Setup front end libraries

The previous step will create the package.json file so you can then install the required npm packages:

npm install --save-dev @inertiajs/inertia
npm install --save-dev @inertiajs/svelte
npm install --save-dev @sveltejs/vite-plugin-svelte
npm install --save-dev svelte

To make sure package.json allows for modules,

"type": "module",
{
  "type": "module", 
  "devDependencies": {
    "@inertiajs/inertia": "^0.11.1",
    "@inertiajs/svelte": "^1.2.0",
    "@sveltejs/vite-plugin-svelte": "^3.1.1",
    "vite": "^5.3.1",
    "vite-plugin-ruby": "^5.0.0"
  }
}

Configure Vite Plugin

Add the Vite Svelte plugin to the project by editing the vite.config.ts file (found in the project's root). After editing it should look like the following:

import { defineConfig } from 'vite'
import RubyPlugin from 'vite-plugin-ruby'
import { svelte } from '@sveltejs/vite-plugin-svelte'

export default defineConfig({
  plugins: [
    RubyPlugin(),
    svelte(),
  ],
})

Next configure the vite.json file (located in the config folder) to point to the correct location for our entrypoint. The sourceCodeDir value needs to be frontend like so:

{
  "all": {
    "sourceCodeDir": "app/frontend",
    "watchAdditionalPaths": []
  },

In the next step we'll create the entrypoint we refer to above.

Setup Rails Svelte entrypoint

This step was a bit different in the few places I found examples however this seems to be the accepted and most orthodox way of organising the files.

First create the application.js file:

mkdir -p app/frontend/entrypoints
touch app/frontend/entrypoints/application.js

The contents of application.js should be the following:

import { createInertiaApp } from '@inertiajs/svelte'

createInertiaApp({
  resolve: name => {
    const pages = import.meta.glob('../pages/**/*.svelte', { eager: true })
    return pages[`../pages/${name}.svelte`]
  },
  setup({ el, App, props }) {
    new App({ target: el, props })
  },
})

Next create a front end Svelte component as an example.

First create the Home.svelte file:

mkdir -p app/frontend/pages
touch app/frontend/pages/Home.svelte

Now add images under /public/assets/images/ folder. I've added a rickroll.gif for demonstration purposes.

Then add some HTML markup to the Home.svelte component:

<script>
    let src = "assets/images/rickroll.gif";
</script>

<img {src} alt="a random image" />

Generate Rails Code

To load our Home.svelte component we'll need a Rails controller which we'll create like so:

rails generate controller Home index

Then make sure the index method sends the correct response using the Inertia library:

class HomeController < ApplicationController
  def index
    render inertia: 'Home', props: {
      name: 'Inertia Rails'
    }
  end
end

To get the above to work on the main path edit the routes.rb file like so:

Rails.application.routes.draw do
  root 'home#index'
end

Final Steps

We're almost done. In fact we have everything we need but this bit is to make it a bit simpler to run. Create a dev file in the bin folder and make it executable:

touch bin/dev
chmod +x bin/dev

Edit the newly created dev file and add the following bash code:

# !/usr/bin/env sh

if ! gem list foreman -i --silent; then
  echo "Installing foreman..."
  gem install foreman
fi

exec foreman start -f Procfile.dev "$@"

Finally create the Procfile.dev file which is referred to above:

touch Procfile.dev

And then add the following lines. The p flag is important and is what caught me out:

vite: bin/vite dev
web: bin/rails s -p 3000

And that's it! Now you can run bin/dev from your terminal and you should see something like the following:

Inaugurating my first Svelte+Rails app with a rick roll meme

In-person vision transmission

I recently transitioned from leading a product team in a region to a more centralised role overseeing products across multiple geographies. As part of that transition, I needed to onboard the new product lead of that region, ensuring they were fully briefed.

While a virtual onboarding could have covered the basic documents and data points, I knew an in-person handoff was crucial. Slide decks can lay out objectives, milestones, and KPIs all day long, but it would definitely lack that oomph factor of an in-person transmission. This was one of the rituals which warrant an in-person interaction even while almost 90% of our interactions are virtual.

Face-to-face allows for a communication that just doesn't come across the same way over video calls. You pick up on vocal intonations, body language, and can have a true dialogue in the moment. Even the most thorough handoff docs might miss those details.

The purpose of this on-site meeting was to convey the overall product vision to the new product leader. And for that person to evangelize the product vision over time, they need more than just the explicit facts and figures. Performing this type of 'in-person vision transfer' prevents the Big Hairy Audacious Idea from getting lost in translation. You want to convey the vision of the product in a way that truly excites someone at a visceral level - and that's tough to accomplish remotely.

I was originally intrigued by the Theravada Buddhist tradition of Dharma transmission, a ceremonial ritual where the teacher formally empowers a student to uphold spiritual teachings. Once the transmission is complete, the student is empowered to conduct the teachings independently. In a similar vein, when anointing a product evangelist, the goal is to light that flame so that they could be the biggest cheerleader for that product.

The analogy is highly relevant for our purposes here. Similar to this meditative practise of transmission, you're transmitting the essential teachings and learnings of the product and the company. The Vision, Mission, Strategy, Goals, Roadmap. In that order. It's important to get these base fundamentals aligned, as one builds on top of the other, like a pyramid shown below.

Image Courtesy: lennysnewsletter.com

Having said that, all these explicit product and delivery details could definitely be transmitted virtually or asynchronously. This could be easily explained in a one pager, or a presentation, but it's so easy to get it wrong too. You want the new incumbent to be like Hestia, from Greek mythology. The keeper of the flame who ensures that the fire is always burning.

Transmission of the vision virtually, is like drinking soup with a fork. You're missing out on all the subtler aspects of the vision while doing so.

The meeting before the meeting

If you think most product managers spend time in meetings, you're mistaken. The larger chunk of a PM's time is spent in preparation for those meetings - having the "meetings before the meeting", "the meeting", and the "meetings after the meeting."

meetings, meetings, meetings - Marketoonist | Tom Fishburne
Image courtesy: Marketoonist.com

In fact, for most one-way door decisions (decisions that are big and hard to reverse), the pre-meeting phase is quite crucial to getting alignment from various opinionated stakeholders.

The Japanese have a term for this – Nemawashi (根回し) which refers to an informal process of laying the groundwork for a proposed change by talking to the relevant people and gathering feedback and support beforehand.

The concept stems from the practice of Japanese bonsai tree cultivation, where gardeners carefully dig around and trim the roots of a plant to prepare it for transplantation. In a similar way, nemawashi makes you tend to the roots by addressing concerns with the people are invested.

This mental model has come in quite handy for me in navigating difficult decisions and big shifts.

By bringing in skeptics and harsh critics early for "the meeting before the meeting," you can proactively address concerns in a lower-stakes environment. I've found that inviting frank critique through informal sessions like "roasts" creates a safe space to surface objections early on, which I can then incorporate into my plans to build trust.

Facilitating 'roasts' as a part of the pre-meeting phase, helps overcome 'small fires'

If those same objections were to come up in the main meeting unexpectedly, it could derail everything.

One of the biggest lessons I've learned is that your strategy should never surprise the team - the context and key decisions should already be familiar when presented formally. It's far better to put out a few small fires in those pre-meetings than to have to call the firefighters during the main event. It's for these same reasons why wildfires of Baja California leads to devastating forest fires every year, whereas letting small fires burn in Mexico keeps everything in check.

The nemawashi technique prevents conflicts and resistance by making people comfortable with a change before it's officially announced.

It works.

Design that's so bad it's actually good

Recently, a relative sought my help to tweak a badly designed poster on Microsoft Paint.

This was meant to be circulated on Whatsapp as an advertisement for the handyman services his friend was offering in his locale.

He wanted to ‘jazz’ it up and asked if I could help. I quickly fired my Figma and started working towards revamping the layout.

Before pushing some pixels, I took a brief pause—What if crappy design is sometimes good?

Does everything have to be 'designerly' with a better sense of aesthetic? I started searching online, and elsewhere for 'terribly bad but good design' examples.

Craigslist is an example of a successful company with a website that might make Dieter Rams roll in his grave.

usertesting.com

Craigslist website is sprinkled with various UX violations. Lack of responsiveness. No clear hierarchy. Dense information architecture. Lack of contrast. Missing helper text for images. No advanced filters for search.

Despite all this, it's hugely successful attracting millions of users each month to put their local listings. And I'm inclined to think that the so-called 'crappy' design has played a role in achieving the business outcomes of Craigslist.

Part of the reason why it’s clicked is the bare-bones design which gives the impression that it requires minimal development and maintenance resources.

The 'crappy-design' effect makes Craigslist resemble a thrift store more than a high-end boutique, catering to users seeking affordable items.

Let's take another example.

Most of Japanese websites can also be considered under the 'terribly-bad-but-good' category.

Take Kakaku—A popular price comparison site with a text-heavy design displaying. Kakaku is not bad design, per se. It's just so different and unusual compared to western design principles. Just like several other Japanese websites, there is a lot of information condensed into a single page, with multiple columns and minimal white space.

A video that inspired me to write this. Good design is a relative term and is subjected to the culture and context. What Japanese consider as 'good design' is way different compared to Western design principles.

The definition of what 'good design' means not only changes from region to region as shown in our earlier examples, but it also changes year to year.

Google homepage changing every year (courtesy: Web Design Museum)
Image
Batman cape changing year to year

Coming back to the poster for handyman services. I'm beginning to think that there is a particular context in which even the current Microsoft Paint poster might fly well.

If I make the poster too pristine and professional would it then hurt the business? The opposite of what this poster intends to achieve.

If we work backwards from the business outcomes, the perspective around good design changes completely.

And sometimes, the design of the website can be so bad, that it's actually good for the business. Good design is a relative term. And context is everything.

Obsessing over personal websites

Intended Audience—For those of us who have attempted to make a personal website of their own and have guilt-tripped over making multiple updates every year

I’ve been obsessed with my personal website. It’s not even about the views and impressions which I’m receiving. I have one subscriber on my mailing list from my website, and compared to internet writer standards, I am virtually non-existent. 

Yet, I care deeply about this little corner on the internet. It's a place where I optimise for depth over engagement and audience-building.

It’s my resume, my business card, my store, my directory, as well as my own personal magazine. It’s that one place online that I completely own and control.

As David Perell puts it, it's one's own intellectual real estate.

I’m obsessed with it enough to keep revamping my website every year. Just like the corporate re-branding exercises we’re familiar with, I do my own rebranding for my personal website. I reflect on what is NOW my personal brand. I sometimes redo the styling, the fonts and the formatting from scratch and start with a clean slate. I sometimes redo my writing based on my current thinking style and philosophy.

Previously, my favourite font of choice was Karla, then I switched to Poppins, Assistant, Inter, Helvetica Neue and now I'm falling in love with antique serif types (such as the one you see here in this blog)

Every time, I looked back at my previous work as depicted in my website, it felt shitty, and poorly done. But that was the whole point. The new version of yourself would never be satisfied with the previous work you've put in. I think @reidhoffman’s “If you're not embarrassed by the first version of your product, you've launched too late” applies well here.

I now had newer updated standards. My personal website updates have mapped my personal evolution over time, as well as my current standards of quality work.

My first website was a Tumblr blog containing a roll of all my photos under one roof. Back then, I identified myself as a photographer, and wanted to showcase this skillset to the world. Slowly, with more and more experiences, the labels which I used to define myself changed. Four years back, I was labeling myself as a ‘UI/UX designer’, and tried to showcase my love of design through my portfolio site on Wix. The objective of this site was to help in job conversions. I wanted recruiters to look at my website and ask for an interview. My way of achieving this was to put mountains and mountains of work online, and in public.

Whenever there was a reference to my previous work, I mapped the portfolio project links to keyboard shortcuts to make it easier to share with the headhunters on chat windows. And whenever I got an opportunity, I shared my screen, and took them through my work reel. I’d obsessively documented my work and my projects. And I was proud of it all.

 A sure shot way to demonstrate my competence and core skills. Share widely, engage with peers. Debate/collaborate with folks who approach me through my website. Leave behind a legacy online.

And I waited for job offers to roll in. And it did!

My current role as a Product Manager at Noora Health was a result of this building-with-my-garage-door-open-stint.

I had my skin-in-the-game as well as my soul-in-the-game.

This year, I wanted to revamp my personal website with a focus on writing. I’ve been lately viewing writing as a form of thinking, and I wanted to condense and crystallize my ideas into one roof. I redesigned my website again with this brief in mind.

Ghost website now pointing to blog.shreyasprakash.com

This was a setup I was satisfied until I realised how all those javascript animations and micro-interactions were killing the load time and performance of the website. It was at this junction that I discovered this site.

I wanted to make my site more 'simple'. So, I dumped the earlier direction of a '13 megabyte parallax-ative home page prepping for some awwward banner on the top corner of my site'. I just used simple HTML5 tags, deleted all the complex JS and checked the performance speed again.

The site was just 8KB, and had a 100% performance rating as per Google PageSpeed Insights

My current website reflects a lot of my ideals here. I dumped my original plan of making it more 'designerly', and went for simplicity instead. Simplicity is the ultimate sophistication.


Simple not just on the front-end, but on the back-end too. The front end blog is hosted on Ghost, an open-source platform for publishing blogs. The blog currently points to blog.shreyasprakash.com, and I have wrapped it on my personal domain as an external wrapper. I’ve been an aspiring founder/hacker, and have started to care about why and how my blog/website is setup. Also planning to setup a /now page to talk a bit more about my daily diaries and current updates. It would serve more as a one-to-many social network where I could post more ephemeral updates. 

I’m inspired by Derek Sivers to eventually migrate my email service provider as well as my file storage on a digital ocean droplet. Let’s see how it goes!

Instead of routing my internet friends to an external site, I want them to land on my website first. I’ve started to think long term and have come to a realisation that individuals last longer than companies. With the emergence of ChatGPT and other large language models, even a giant like Google is actively contending with significant competitive pressures. This situation highlights that no company, regardless of its size, is shielded from market challenges and competitors.

I want my website to be a definitive place to get everything I create. I will still continue to put stuff on some other company’s sites (such as Twitter tweets). However, they would be secondary copies and not the primary source.

Eventually, I want this to be my 'root'. I can fork it wherever I want.

English is the hot new programming language

It's the best time to learn coding, no matter what your profession is.

Intended Audience—Indie no-code developers, digital marketers and other non-tech professionals working in tech

I made a resolution for 2024 to learn Ruby on Rails, a controversial web development framework famous for maximising developer productivity. In the business of building and growing products, I wanted to be a self-taught developer too.

Sketch inspired by Henrik Kniberg's presentation on cursor.sh

The goal behind my trite, cliched new-year resolution was to get to a point where I could build apps in a weekend. I have been day-dreaming about a state where—I get a shower-thought, I write code, and in 2-3 hours, I have a production-grade software that’s ready to roll. An end goal of shower-thought driven software engineering was my final objective.

After a brief affair with no-code apps where I tried to achieve this agility (Bubble, Softr, Glide, Framer), I realized that most of these apps were platform-dependent. You couldn’t export your code. You had more lock-ins, and lesser customisations. It was this meme all over again:

I realized that hard-coding was the only way. So I dived deep into Ruby on Rails this year. And to ingest and digest it as much as I can, I’ve been racing past the Learn Enough tutorials by Michael Hartl for the last two months. I also ended up binge watching screencasts from Ryan Kulp’s Founder Hacker course for an added perspective. The first red-pill moment was when I built my first ruby script to solve my own scratch on making wikipedia imports into Obsidian easier, I started gaining more technical sophistication to make quick things and ship it for myself.

My progress in hacking my way around, learning about enough coding to be dangerous, and also racing through different steps of the web development (Git, IDEs, HTML, TypescriptCSS, JS, Ruby, Ruby on Rails) would have not been possible without asking the most stupidest of my questions to ChatGPT as a newbie, amateur, rookie developer.

From the Founder Hacker course, where Ryan Kulp builds a Ruby on Rails app live on Youtube

I’ve found bugs in the code, copied the error without understanding into ChatGPT and then again back to the IDE to make changes and see if it works. And I’ve realised that the barrier for designers to code and bring their designs to life is getting narrower over time. You’re literally ‘spellcasting’ to get your code out, by just chatting with the LLM. 

From tl;draw to Diagram and Galileo AI, we’re seeing instances where prototypes are being built at the speed of the ‘mouth’. Every type of programming becomes a conversational design piece – text to text, text to video, text to code, text to game, text to UI, text to 3D prints, etc.

Over time, I’ve realised that I am not actually learning Ruby on Rails. I’m learning a way to ask around and figure out in plain English. I’m building stuff by prompting. To name a few:

  • A simple web UI
  • A telegram chat for meal planning
  • Ruby on Rails UI components adapted to TailwindCSS

LLMs are the closest thing in the real world to magic, and prompts are the magic spells. Just like spelling wingardium leviosa, you’re typing carefully curated prompts. We’re seeing examples such as Promptbase where prompts are secret magic-spells being traded on the marketplaces. (I'd earlier shipped Prompt Hero to ride on this wave)

PromptBase | Prompt Marketplace: Midjourney, ChatGPT, DALL·E, Stable Diffusion & more.
Search 100,000+ quality AI prompts from top prompt engineers. Produce better outputs, save on time & API costs, sell your own prompts.

With the rise of LLM-backed coding assistants, I’m not even copy+pasting into ChatGPT questions anymore. LLMs are being tightly integrated into the codebases through these coding assistants. I’ve been recently using cursor.sh, an AI-native IDE. They can now read, explain code, document code, write code, autocomplete it, diagnose issues, and even perform arbitrary IDE tasks. Everything is pretty cool, right?

In the final stage of developer productivity, AI-native IDEs seem to be the direction where the world is heading. English is the hot new programming language, and I’ve been coding in English using these AI-native IDEs. 

We’re now seeing a new breed of design engineers, who could both design and ship code at the same time, improving the production cycle between building and shipping software.

It somehow seems like a great time for anyone, be it an architect, product manager, roadside cartoonist, sociologist, to be a design-engineer first. If all we need is english to code and build products, then who is stopping us? 

Everyone can now do shower-thought driven software engineering if all that’s needed is crafting good prompts.

Update: Devin enters the chat.

The role of taste in building products

Taste is one of the hardest things to talk about in the product circles. So, let's talk about taste.

Take Marc Lou, a familiar figure within the Twitter Indiehacking circle. He's garnered attention for openly sharing his journey as a product builder. This transparency has piqued interest in his projects well before their launch, as followers have grown to appreciate his distinctive approach. A notable instance of this was the excitement around his AI logo generator, which swiftly climbed to the top spot on Product Hunt. Despite its remarkable simplicity, the product captured the audience's attention, largely because the audience already understood the creator's taste.

LogoFast - Product Information, Latest Updates, and Reviews 2024 | Product Hunt
Choose your hero icon, splash on some color magic, give it a twirl, and voilà – your stunning logo’s ready to shine! 🌟 Or let our AI wizard craft the perfect emblem for you, no wand-waving required!✨

LogoFast on Product Hunt

Unlike indie hackers, and other product builders, companies do prioritise rigorous A/B testing and data-driven decision-making. As the projects involve larger teams, and processes, they subscribe to the philosophy of 'letting the data do the talking'. Take this snippet from Flo Health's Medium blog here for example. Each and every feature is rigorously tested and experimented before going live.

Flo experiments dashboard as shown on their Medium blog

However, a shift is occurring in this mindset.

People are considering taste and sensibility, despite the fact that taste is one of the hardest things to talk about.

Brie Wolfson describes this inexplicability in his essay on Taste—

When I ask people what they mean by “taste,” they’ll stumble around for a bit and eventually land on something like “you know it when you see it,” or “it’s in the eye of the beholder.” I understand. Words like taste are hard to pin down, perhaps because they describe a sensibility more than any particular quality, a particular thing. We’re inclined to leave them unencumbered by a definition, to preserve their ability to shift shapes. But I don’t think we have to. And for the past several months, I haven’t been able to resist the urge to try to articulate taste.

This comes, in part, from a place of wanting to be precise — now that the term is such a frequent and varied part of our lexicon, it runs the risk of losing its meaning.  But I also believe taste is something we can and should try to cultivate. Not because taste itself is a virtue, per se, but because I’ve found a taste-filled life to be a richer one. To pursue it is to appreciate ourselves, each other, and the stuff we’re surrounded by a whole lot more. So, how to wrap my arms around this term in a way that captures its spirit without flattening it?

I can’t think of a piece of writing that does this more effectively than Susan Sontag’s “Notes on ‘Camp.’” In her words, “a sensibility is one of the hardest things to talk about... To snare a sensibility in words, especially one that is alive and powerful, one must be tentative and nimble. The form of jottings, rather than an essay (with its claim to a linear, consecutive argument), seemed more appropriate for getting down something of this particular fugitive sensibility.” 

Consider the approach of Linear, a company that diverges from the data-dominated decision-making model. Linear emphasizes the importance of taste and opinion in validating ideas and assumptions, rather than relying solely on A/B testing and metrics. This approach is about trusting one's gut in a product's readiness for launch, based on qualitative feedback and iterative improvements.

With certain projects, we might pull up specific data or metrics to see if the data gives us any more insights, but it’s not the way we make decisions. We don’t do A/B tests. We validate ideas and assumptions that are driven by taste and opinions, rather than the other way around where tests drive decisions. There is no specific engagement or other number we look at. We beta test, see the feedback, iterate, and eventually we have the conviction that the change or feature is as good as it can be at this point and we should release it to see how it works at scale. — Karri Saarinen, CTO of Linear

This perspective is shared by Jason Fried, Co-Founder of 37 Signals (makers of Basecamp and Hey). Fried challenges the notion that everything must be A/B tested, questioning the practicality and relevance of 'statistical significance.'

I am not driven by data, or I don't have different P&Ls for each product in a way where we're looking at them very carefully. It's in total, collectively, are we making more money than we spend? That's the only thing we ultimately look at, whether or not this product is more profitable than that product, and this is behind that, it's all the things we do. It's all the things we do. I don't even think you can actually draw lines back to everything and go, "That was worth it. That wasn't worth it." What is the value of saying thank you to somebody? Would you want to A/B test that and, if it turned out that it was worse to say thank you to somebody, would you not do that? No, you would do it because it's still the right thing to do. — Jason Freid, Basecamp

He argues for a more holistic view of success, focusing on overall profitability rather than the minutiae of individual product performance. Yet, the essence of 'taste' remains somewhat enigmatic. It involves an understanding of what makes a project or product resonate, balancing quality, appeal, and budget.

But there are some great examples showcasing this. Apple's approach to sustainability reporting exemplifies this. Apple provided a new spin to the boring 10-page report format, focusing instead on a creative ad campaign outlining their efforts in a smart, eye-catchy fashion. They could have done the same thing in a more convenient format, but they chose to do it differently.

Apple provided a new spin to the boring 10-page report format, focusing instead on a creative ad campaign outlining their efforts in a smart, eye-catchy fashion.

As Brent Schlender describes in "Becoming Steve Jobs," Apple's resurgence from near-bankruptcy was driven by Jobs' ability to harness 'trusted auteur directors' to realize a singular vision. Airbnb's Brian Chesky also embodies this concept of taste. His 15-year journey in developing a nuanced understanding of both the demand and supply sides of Airbnb's service has culminated in a distinct, qualitative essence that defines the brand.

Taste is nothing but intuition translated to action.  It's your System 1 in action. A firefighter immediately notices thick smoke billowing from the house. All the years of training and experience has honed his instincts, and snap-second judgements. In split seconds, the firefighter is deciding on calls to backup, begin immediate entry, as well as identify escape routes to rescue victims.

Taste is nothing but intuition translated to action.

Who should steer the course of a product's development – data-driven product managers or visionary auteurs? Should the focus be on relentlessly testing every modification and feature addition, or should we trust in the guidance of these auteur directors to fulfill their promise of impeccable taste?