
Ask HN: Co-founder is addicted to new features - whateveracct
My non-technical cofounder (who has majority share) won&#x27;t stop thinking of new features he wants us to deliver ASAP. The problem is, as we&#x27;ve kept building features, the system itself is getting less stable and we&#x27;ve accumulated cut corners over time to deliver ASAP. We (the engineers) have made it clear that we need to spend many weeks refactoring, adding tests, and doing other improvements if we want to get to a level where we can successfully land &amp; support a big customer.<p>Every time we find a stability issue &amp; figure out a fix, he asks for LOE and if we don&#x27;t say we can turn it around in a day or two he shoots it down and says we have too many features (which he just thought of in the last 2 weeks) to do.<p>On top of that, he is always promising to show current &amp; potential customers new features next week - features that haven&#x27;t even been started or thought out! So we scramble &amp; cut corners to get them demo-ready.<p>A few months ago, we pushed back pretty hard and said after our next milestone, we need time to pause features &amp; work on stability, and he said we would. Well, it&#x27;s been a few months and now there are documents and documents of new features we Need to build in order to be Successful. It&#x27;s getting harder to buy since half of the features we did build get little to no use.<p>So what can I do? Despite owning a large chunk of the company, it doesn&#x27;t feel like I have any say when it comes to how I spend my time and energy. I&#x27;m trying to bake adding tests, refactoring, etc into my Definition of Done for feature work (thus slowing down those features too.) But it feels like a piecemeal bandage.<p>I&#x27;ve read these threads on HN before and half the responses tend to be &quot;engineers obsess too much over quality - focus on delivering business value.&quot; Well, plenty of business value has been and is being delivered. And when this guy is also always complaining when thinks break in complicated ways, it feels like stability would provide business value.
======
codegeek
I used to be that founder. Until very recently. So Let me share my
perspective. I was always worried that we are not doing enough
revenue/business because we are missing THAT one feature compared to our
competitors. Another reason was that whenever a prospect asked for some
specific feature that we didn't have, I started thinking we need it in our
core product without realizing may be no one else will ask for it again. After
doing this for 6+ years, I have learned my lesson when my CTO basically told
me that "you are finding excuses not to sell and if you think more features
will get you more sales, you are stupid". He said it in a nicer way but I
finally realized it. Wasn't easy. Still sometimes I tend to get in that mode
but now I know better. Glad my CTO had that talk with me.

I suggest you sit down with him and discuss his point of "focus on delivering
value". Instead of blaming him or telling him that he is wrong, ask him why he
believes that adding new features is the only way to add value. Is he worried
that we won't get more sales without new features ? Try to understand his
mentality on why he is so obsessed with features and may be then you can get
somewhere.

If he doesn't listen, connect him with me (half joking :) and I will tell him
that as a fellow founder (even though I am myself technical but don't write
code anymore), features are not what we should focus on to get more revenue.

------
gus_massa
How many cofounders are there? How is the equity split? 55%-45%? 60%-40%?
95%-5%? Do you have that in written?

Do you have any customers? Are you (and the rest of the team) getting paid?

------
factorialboy
Use security as a negotiation anchor. You don't want to be in the news for
wrong reasons. Even the non tech founder should understand that.

------
kirillzubovsky
A couple of things in no particular order.

\- If this is a new start up and you're just trying to get product market fit,
then you don't need to spend time on making your systems stable to be able to
support a big customer. First, you have to do whatever it takes to get a
customer, and then a big customer. Plenty of really successful startups have
ridiculously messy code under the hood, and that's OK because the job isn't to
write clean code, the job is to create product that people love.

\- If you are the CTO of this company, then it is your job to figure out what
can be done under what time frames, and despite your cofounder needing more
features, it is your responsibility to deliver them. Therefore, your cofounder
needs to understand this, but since they are non-technical, they probably have
no idea. This is on them to educate themselves, but you can help them. Of
course, it is also on you to have a backbone and be able to tell your co-
founder "No." It sucks, it doesn't feel good, but if you want to be a CTO,
then being able to communicate is part of your job.

\- What is your assessment and how you are doing financially with your
customers? It sounds like your cofounder realized that you haven't achieved a
product market fit yet, and they are trying new features to find what
resonates with the customer the most. That is a good approach, but even better
approach is to figure out what your customer needs before you build any of
those features. It's hard to say exactly how to do given that we don't know
anything about your application, but people who have figured out how to do it
achieve great success. See my notes on [how Rahul started
Superhuman]([https://smashnotes.com/p/acquired/e/superhuman-with-ceo-
rahu...](https://smashnotes.com/p/acquired/e/superhuman-with-ceo-rahul-
vohra)), or how [Ramon made millions with a cheesy
blog]([https://smashnotes.com/p/my-first-million/e/blogging-his-
way...](https://smashnotes.com/p/my-first-million/e/blogging-his-way-to-9m-in-
cash-ramon-van-meer)). Those are just a couple of examples that come to mind
immediately.

\- Lastly, if your cofounder is asking for more features with little results,
they are simply insecure and scared the company is about to fail, but instead
of admitting what's happening to you and the team, they are hoping to find a
way out of this before the collapse. They should talk to other "managers" in
the company and find a way together, but they are scared, they are just a
little mouse stuck in a dark-dark corner. If that's the case, see if you can
figure out how to help them out, if it's possible.

Good luck!

~~~
afarrell
> the job isn't to write clean code, the job is to create product that people
> love.

Note however that as a person, your job is also to keep yourself mentally
well-balanced. If your mind is crushed under the weight of un-encapsulated
complexity, then thats a problem.

~~~
croh
Doing proper market survey with reality check and knowing your customer is
also a job. Many times non-technical people don't understand this. They think
that THEY ARE CONTRIBUTING BY BRAINSTORMING AROUND NEW FEATURES. As someone
has mentioned in other comment - "you are finding excuses not to sell...". You
should ask him to read 'rework' by DHH and Json Fried

------
Jugurtha
Let's talk about stability and tests, and what you can do whether there is a
change in product development or not: the first few commits in our iko.ai
project were to use a plugin architecture so that new features were
apps/plugins we could activate/deactivate from a config file.

These apps live in separate repositories and are loaded by the core. The core
is tiny and most of the work is on the extensions. Similar to kernel vs.
drivers.

Why we did that? We've been building custom enterprise data products for
almost seven years. Many of these products were so custom we couldn't sell the
same product to another client if we wanted. It is not just about code reuse
on the function or library level, it's "functionality" refuse as in you plug
in a forecast extension, you plug in a sentiment analysis extension, etc.

A couple of years ago, a college acquaintance came to me and asked if he could
hire us to deliver a certain product. We practically had the product ready but
the features were baked in the product.

So, now, we have features as independent applications that get loaded,
displayed, and interacted with easily.

This allows you to decouple functionality and contain instability. It also
allows you to add or remove features easily. You want to kill a feature? You
don't even have to remove its code. Just don't load it. Maybe you'll need it
in the future and you can work on it independently once you _sell_ it.

This also simplifies hiring and is good for retention. The activation energy
for a New contributor is dramatically lowered, since they don't have to
understand the whole codebase, which takes more time. You can give them one
extension to work on.

Retention is improved because there's a path to onboard code wise, and people
can start working and be successful from day one and get acquainted with the
codebase as they gain experience, extension by extension. They can also take
ownership of that extension, which when the company grows can be a business
unit or a company in and of itself.

That's in terms of code architecture. This is useful whether you change your
sales/product strategy and tactics or not.

Now, there's a difference between a problem and a solution. People usually
tell you about their problems in terms of solutions they imagined. Extracting
that in terms of "job to be done" and in terms of "what's the underlying
problem the client/user/prospect/customer is trying to solve for which they
came up with that solution" comes naturally for some, but definitely can be
learned.

The answer to "can we have integration with Kafka" is not "sure we'll get
right to it" but further inquiring about the workflow and the problem they
want to solve. What is the _actual_ workflow, not the one the executive at
some company has read in a McKinsey report during breakfast.

Second, did you sell the existing features or not? If not, adding more
probably won't solve the problem.

One of the common remarks prospects say is: "solutions x, y, z have that
feature" and you want to tell them "and yet here we are". A nicer elicitation
question is "what's been your experience with x, y, z". The answer is
invariably "we don't use them". A more naive person would have jumped on the
occasion and make that feature top priority because the prospect large company
has talked about it in the meeting. But that question makes it obvious that
even that feature won't make thé sale. You develop it and perpetuate the cycle
of wasting time on whimsical demands. The previous question can be followed up
with "interesting, what are you using instead/why aren't you using x, y, or z
?"

The point is if that feature or set of feature was that important, they'd
probably be no meeting.

One caveat is that certain features truly do matter, and having the above line
of questioning will surface those because the answer will "we don't use them
because (compliance/security/scalability/etc). For entreprise, it's rarely if
ever about price.

Also, the meeting can be to gather more information about your product because
they're weighing the pros and cons of developing it internally. They might
even have started and are gathering how you did it, especially if they ask
questions about your team, how long it took you to build that version of the
software, etc.

Again, extract problems not the implementation of the client.

There is an effort to educate the CEO on product building, and on sales too.
Ideally, they'd be selling what you already built and you would be prying open
business use cases to find underlying problems to build for, and then sell
that too.

Ideally, meetings should involve both sales and engineering. The decision to
build is taken after the meeting, which is to gather information.

And ideally, the CEO should be selling your existing features of which state
you are ashamed, and trying to get a price for them that almost no engineer
would dare to ask.

------
afarrell
So I know "person with a neurological condition sees everything through that
lens" is a genre that gets old real quick, but as a dude with ADHD I can't
help but read

> it doesn't feel like I have any say when it comes to how I spend my time and
> energy

and conclude that you are asking for advice on how you can both can do
Executive Functions.

\------------------------------------------------------------------------------------------------------------

Emotional advice:

1\. Say to yourself, "This is hard. This is worth it. We will carry on
through." or something in that spirit.

2\. Embrace homeostasis.

A company is made of living humans responding to an environment. There is no
"finally land and support a big customer". There is no big-bang refactor that
cleans everything up. There is no "finally do the demo that gets things to be
'Good'". The company will always have endless series of problems until it
dies.

Breathe in. Breathe out. There is no final destination. The path just goes on.

3\. All paths have endless problems, but there are better and worse paths.
Choose the path with the problems that are more rewarding (personally and
financially) to be solving week-by-week.

4\. Embrace the discomfort of risk with balance. Neither lose yourself in it
nor try to escape from it.
[https://www.youtube.com/watch?v=7hx4gdlfamo](https://www.youtube.com/watch?v=7hx4gdlfamo)

Oh, and both continually grow in the practice of setting boundaries and
avoiding self-deception. (Warning: this can also be hard)

\------------------------------------------------------------------------------------------------------------

Directly actionable advice:

1\. Write "Q4 2020" at the top of a whiteboard.

2\. Draw an X and Y axis. Label the Y axis "Impact" and the X axis "Effort"

3\. Get a bunch of notecards and magnets/stickytack.

4\. Write each business outcomes on one notecard. Phrase these as capabilities
"User can do X" or "CFO can quickly report Y".

5\. Get a huge number of Green and Blue dot stickers.

6\. Every business person in the room puts a green dot on a notecard if they
have a way they would observe the revenue/conversion/sales/risk impact within
2 weeks of the feature/outcome going life.

7\. Every engineer in the room puts a blue dot on a notecard they feel
confident in their ability to estimate the effort of doing it.

8\. Plot the notecards on the Effort and Impact axis in comparison to one
another.

Argue. Endure the discomfort of arguing. Do not agree to disagree unless you
think you're only 20% out-of-alignment or agree to take the notecard off the
board.

~~~
afarrell
For some reason, I completely forgot about the pandemic when writing the
second section...

