<div class="available-content">
<div class="body markup" dir="auto">
<p>When I was starting out I didn’t have a large team or a long runway to experiment with products and features. Despite those constraints, I was always the one who advocated getting the design just right and adding a few small features that would make all the difference in the product.</p>
<p>&nbsp;</p>
<p><strong>Building products is exciting work! </strong>The thrill of putting pen to paper, sketching things out and seeing those things come to life is the trip that most product founders live for.</p>
<p>&nbsp;</p>
<p>It is also a primary leading source of death for most startups.</p>
<p>&nbsp;</p>
<p><strong>Building something that no one wants.</strong></p>
<p>&nbsp;</p>
<p>I have become more self-aware when I start to go overboard with product development over the last couple of years. However, days like today I fail at holding that line. During a product scoping meeting I bulldozed my way through getting an additional piece of software added to the scope.</p>
<p>&nbsp;</p>
<p><strong>I am very thankful to have a team around me that is able to use inversion to get my heads out of the cloud and onto what truly matters.</strong></p>
<p>&nbsp;</p>
</div>
<div class="body markup" dir="auto">
<blockquote><p><strong>Getting engaged customers. Nothing else matters in the early stages of a startup.</strong></p>
<p>&nbsp;</p></blockquote>
<p>Here are a couple of things I am doing to hold myself more accountable and not be the person on the team who is continuously pushing scope creep:</p>
<ol>
<li><strong>Our <a href="https://identifi.substack.com/p/early-optimal-work-cyclesa35ee6265df9" rel="nofollow ugc noopener">shorter work cycles</a> are the ultimate constraints</strong> as we can only fit a very specific amount of work into the queue. While sometimes I am the product managers and designers worst nightmare, the damage remains limited to the design stage and doesn’t get pushed to engineering.</li>
<li>We have <strong>created a meta map of the top line functionality of the product </strong>which avoids us moving wide into tangential new features. While this doesn’t stop going more granular on features it does slow down the surface area of feature/scope creep to a limited zone.</li>
<li><strong>Empowering the team to challenge and use inversion frequently</strong> about why the feature may make the experience worse for users. This is hard to do as founders can be very forceful with their vision. It requires a high level of self-belief in the team’s capability in their own domains.</li>
<li><strong>Using time to value metrics to benchmark experience.</strong> In the early stages of product building any feature or scope addition that doesn’t make the initial experience and establish habit loops isn’t accretive.</li>
</ol>
<p>Building a good product is difficult. <strong>There isn’t a perfect formula to how big or small your MVP needs to be. </strong>It depends on who your <a href="https://wordpress.highoutput.io/who-is-your-customer-2/">customer</a> is, the severity of the problem you are solving for and how quickly you can deliver a meaningful experience to the customer that makes them stick.</p>
</div>
</div>
<div class="visibility-check"></div>
<div class="post-end-cta-full">
<div class="visibility-check"></div>
</div>
