<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Disha Kedia</title>
    <description>The latest articles on DEV Community by Disha Kedia (@disha_kedia_189c55b5ae815).</description>
    <link>https://dev.to/disha_kedia_189c55b5ae815</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4138756%2Fe2477951-7551-4eee-a68e-c4ef2cd40591.png</url>
      <title>DEV Community: Disha Kedia</title>
      <link>https://dev.to/disha_kedia_189c55b5ae815</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/disha_kedia_189c55b5ae815"/>
    <language>en</language>
    <item>
      <title>We often start product conversations with: “What should we build?”</title>
      <dc:creator>Disha Kedia</dc:creator>
      <pubDate>Wed, 23 Sep 2026 05:59:23 +0000</pubDate>
      <link>https://dev.to/disha_kedia_189c55b5ae815/we-often-start-product-conversations-withwhat-should-we-build-11j1</link>
      <guid>https://dev.to/disha_kedia_189c55b5ae815/we-often-start-product-conversations-withwhat-should-we-build-11j1</guid>
      <description>&lt;p&gt;I’m starting to think the better question is:&lt;br&gt;
“What do we actually need to learn?”&lt;br&gt;
Because an MVP can become surprisingly large.&lt;br&gt;
Login.&lt;br&gt;
Payments.&lt;br&gt;
Admin dashboard.&lt;br&gt;
Notifications.&lt;br&gt;
Analytics.&lt;br&gt;
Multiple user roles.&lt;br&gt;
Before you know it, the “MVP” has turned into a full product roadmap.&lt;br&gt;
But if the purpose of an MVP is to validate an idea, shouldn't the first version focus on answering the biggest unanswered question?&lt;br&gt;
From a product/business perspective, I’ve started looking at development differently:&lt;br&gt;
Not everything needs to be custom-built.&lt;br&gt;
Some parts of an application are already well-understood engineering problems.&lt;br&gt;
The interesting engineering work is often in the parts that are specific to the product:&lt;br&gt;
— the workflow&lt;br&gt;
— the business logic&lt;br&gt;
— the user experience&lt;br&gt;
— the integrations&lt;br&gt;
— the thing that actually makes the product different&lt;br&gt;
That doesn't mean “never build from scratch.”&lt;br&gt;
It means being intentional about where you spend development time.&lt;br&gt;
Working around Founder’s Office conversations has made me realise that development speed isn't only about how fast engineers write code.&lt;br&gt;
Sometimes, it starts much earlier:&lt;br&gt;
with deciding what doesn't need to be built yet.&lt;br&gt;
Curious to hear from developers and product people here:&lt;br&gt;
What's one thing you think teams overbuild in their first version?&lt;/p&gt;

</description>
      <category>webdev</category>
      <category>productivity</category>
      <category>product</category>
    </item>
  </channel>
</rss>
