Don't think you can continue to relate to your customer. Instead, make a list of the outcomes you want, then make a guess what will get you there based on data and research.
<ul>
<li><ul>
<li>If you don't have the volume of data, start with qualitative feedback from user surveys or testing.*</li>
</ul>
</li>
<li>Use competitive analysis. Have your competitors achieved a similar outcome to the one you like? How can you build on their ideas?</li>
<li>Interview people who you want to have as your target audience. What do they use that's similar? Why might they not choose a product like yours?</li>
</ul>
Once you have some working hypotheses, you can start quantitatively measuring results to drive future brainstorming.

Generating ideas

After you brainstorm, you may have many initiatives. After you hit product-market fit, you need to allocate responsibility across teams and empower them to work without the leadership knowing everything. Thematic org areas include:
<ul>
<li>Core product: How to make typical use of the product better.</li>
<li>Signup experience: How to bring more people into the product.</li>
<li>Internal tools: How to optimize the way you're working with infrastructure.</li>
<li>Content: What content do you present to users? How?</li>
<li>Community: How to set up communities for success.</li>
<li>Channels: Where and how to engage with users outside the core product.</li>
<li>Monetization: How to sustain what you're doing.</li>
</ul>

Modular execution

The CEO should cede a large amount of control. The CEO should shift from caring about the design of the product to focusing of the design of the organization.
<ul>
<li>Once a founder or CEO gives up the need to know everything, its easier to reorganize along thematic lines.</li>
<li>Each team needs to be able to drive themselves forward with their own point people.</li>
<li>Focus on handing out prioritites, not tasks. Then let your people be creative about their own execution.</li>
<li>A holistic focus is recommended over a pure tech focus.</li>
</ul>

Give up control

With the growth of your organization, consistently message the same things again and again. Templates ingrain this practice.
For instance, at Reddit, whenever you're about to run a test, you already have the format of an email to explain what you're testing. The template consists of fields where you'll insert the results.

Using templates

There is such a thing as startup puberty and it occurs when your product starts to gather momentum. A startup may be so busy working on getting to this stage that they are caught off guard and may not be ready for the change. The most important changes for a product:
<ul>
<li>You are no longer your customer. Once you hit product market-fit, you need more data as you can no longer reasonably represent all your customers.</li>
<li>You have the ability to test much more. At this point, you can start optimizing because you're pulling enough users or customers to correlate product tweaks with behavior.</li>
</ul>

Crossing the chasm

As a company matures, three major areas of product development change:
<ul>
<li>How you generate ideas</li>
<li>How you execute those ideas</li>
<li>How you continually build on those ideas.</li>
</ul>

Areas of change

The shift from product-market-fit to growth disrupts far too many promising startups.
Companies at every stage can learn how to create effective, replicable, and durable product development systems using a few tactics.

Creating scalable systems

<ul>
<li>Pick only a few hard-and-fast rules.</li>
<li>Provide autonomy between firm commitments.</li>
<li>Be clear about the role of product ops.</li>
<li>Just start. Rather start something in ops than to have a master plan and the process figured out. Start light.</li>
</ul>

Preventing rigidity

The transition needs to happen when:
<ul>
<li>The CEO or co-founders can't contain everything in their heads and don't know what's happening in various parts of the product.</li>
<li>You're trying to expand the product, which requires more work to understand users.</li>
<li>Existing staff members are responsible for too many different areas.</li>
</ul>

When the transition is necessary

New needs mean you need more people. To set people up for success, you need to make your product and engineering teams modular. Then you can split up problems that people can work with independently.
As you grow, your leverage will be in having many autonomously led teams, working side by side. This will enable you to scale easily later.

Modular teams

The idea is that product management can no longer say what they think users want. They need to predict what outcome a feature will have.
In the beginning, you don't have the data you need to do this. Your company, in itself, is your hypothesis. As you start to grow, your ability to make educated guesses becomes the core and fuel for making your product better.

Hypothesis-Driven Product Management

It is helpful when you brainstorm to separate idea generation from idea evaluation. Write down every idea. Then trim your list by applying the feedback you've received through user tests, surveys, and other inputs. Prioritize this filtered list:
<ul>
<li>How important is the outcome this idea will serve?</li>
<li>What is the likelihood of success?</li>
</ul>

Prioritize the distilled list

<ul>
<li>Appoint a business owner for each thematic area who is responsible for driving KPIs, managing stakeholders, and communicating changes.</li>
<li>Minimize existing cross-team dependencies.</li>
<li>Set quarterly operational targets. Tie individuals' OKRs to objectives.</li>
<li>Have the founders or executives direct the smaller thematic teams by setting minimal but big company-wide objectives, and allocating resources.</li>
<li>Continually reevaluate where there are bottlenecks in the system and address them.</li>
</ul>

Initiating the transition

As your company matures, ensure to appoint someone to care about the holistic experience.
<ul>
<li>This person should be focused on collecting and communicating data coming out of experiments, and</li>
<li>Guiding everyone to build features and run tests that connect to company goals.</li>
</ul>
If you don't have proper communication on your product team, many individuals may pursue their own goals for their own feature, causing a sprawl of your product.

Modular teams

Similar ideas to Modular teams

Setting and prioritizing goals as a principal engineer

Rule number 1 (Multiple Income)

Give people what they want