Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing stuff is never obvious yet often better

gkogan.co

Post reply on HN
Print view View original

141–150 of 196 posts

Re: Removing stuff is never obvious yet often better

#141

Post by albedoa »

shubhamjain wrote: post #60
CookieCrisp wrote: post #56

Earlier quoted context omitted.

I feel like that example is missing some context - if signups did increase then their experiment was successful - we aren’t here to make pretty pages, we’re here to make money.

The problem is that it's easy to prove that signups are increasing, and lot harder to prove that there was a measurable increase in number of paying users. Most A/B tests focus on the former, very few on the latter. We had a free plan, and most users who signed up never made a single API request. So, assuming that the increase in signups is driving more business is just foolhardy.

> The problem is that it's easy to prove that signups are increasing, and lot harder to prove that there was a measurable increase in number of paying users.

Okay? The A/B test sought to measure which of two options A and B led to more signups.

> So, assuming that the increase in signups is driving more business is just foolhardy.

Your "A/B test enthusiast" was not testing for or trying to prove a causal relationship between increased signups and more business.

If he made the claim separately, then that is the context that is missing from now multiple comments.

Re: Removing stuff is never obvious yet often better

#142

Post by Rastonbury »

ljm wrote: post #139
otherme123 wrote: post #115

Earlier quoted context omitted.

> Of course if you hide the fact that your product might cost a lot of money from your users, more of them will sign up The problem with their calculator was that the users introduced slightly wrong data, or misunderstand what means some metric, and suddenly a 1000x the real price was shown. Their dilemma was "how to fix those cases", and the solution was "get rid of the messy calculator". But they are not hidding a…

Being a complete cynical bastard here but I sometimes feel like these calculators are actually meant to obfuscate and confuse and the result is that a startup worried about scale is going to pay over the odds and then deal with ‘rightsizing’ after the costs get out of control. I felt like that with elastic serverless’ pricing calculator which on the surface looks perhaps cheaper or more efficient than a normal manage…

Can't speak for everywhere of course, but the places I have worked nobody likes spikes or over commitments. The customer is shouting at your people, salespeople and support spend time and get stressed dealing with them, leadership gets bogged down approving bill reductions. Even if granted, customers remember the bad experience and are probably more likely to churn

Re: Removing stuff is never obvious yet often better

#143

Post by Rastonbury »

sethammons wrote: post #119

Is it standard to use percents of percents in conversion tracking? Going from 20 to 23% conversion rate is not a 15% increase in conversions, it is 3%. If that is the kind of shenanigans being played, there is something else to remove

It is. To simplify, if every conversion makes the company makes $1 and 100 prospects enter this funnel, going from 20 to 23% means they make $23 instead of $20

Re: Removing stuff is never obvious yet often better

#144

Post by layer8 »

grujicd wrote: post #74
refibrillator wrote: post #53

Upvoted to spread the immense wisdom in this post. But golly I must say the line can get blurry quickly. > Would anything of value be lost if this or that chunk of it was removed? In early stage projects I’ve seen this mentality backfire occasionally because it’s tough to estimate future value, especially for code and data. For example, one time in a greenfield project I created the initial SQL schema which had some…

Main issue with adding something you might need in the future is that people leave, people forget, and then, one year later, there's some metadata column but no one remembers whether it was already used for something. Can we use it? Should we delete it? Someone remembers Knight Capital and spectacular failure when old field was reused. So it's always safer to keep existing field and then you end up with metadata and…

Easy solution: Add a comment in your schema-creation SQL script explaining what the purpose of the column is. Or some other equivalent documentation. Stuff like that should be documented in any case.

Re: Removing stuff is never obvious yet often better

#146

Post by blueboo »

latexr wrote: post #137

Here’s a followup for the author: follow your own advice. Remove the “Psst... Get the next post in your inbox” interruption midway through your post. Dare to remove the stupid button that follows you around as you scroll. I counted five obvious ways to subscribe on that page alone. Five! Do you really need to shove them in our faces and in the middle of the freaking content? Do you think you get more subscribers by i…

IIUC the lesson of blog SEO is that, if you want to grow your readership, copious attention-co-opting calls to action are unambiguously worth the annoyance foisted on discerning readers.

What’s respectful to users is a separate (but not wholly unrelated) question…

Re: Removing stuff is never obvious yet often better

#147

Post by 6510 »

ljm wrote: post #139
otherme123 wrote: post #115

Earlier quoted context omitted.

> Of course if you hide the fact that your product might cost a lot of money from your users, more of them will sign up The problem with their calculator was that the users introduced slightly wrong data, or misunderstand what means some metric, and suddenly a 1000x the real price was shown. Their dilemma was "how to fix those cases", and the solution was "get rid of the messy calculator". But they are not hidding a…

Being a complete cynical bastard here but I sometimes feel like these calculators are actually meant to obfuscate and confuse and the result is that a startup worried about scale is going to pay over the odds and then deal with ‘rightsizing’ after the costs get out of control. I felt like that with elastic serverless’ pricing calculator which on the surface looks perhaps cheaper or more efficient than a normal manage…

My cynical take: I make things that look hard to make to impress you but if you make them for me I feel my money is going into the calculator rather than the product.

Re: Removing stuff is never obvious yet often better

#148

Post by onlyrealcuzzo »

strken wrote: post #69
bruce511 wrote: post #54

Earlier quoted context omitted.

>> Of course, the pricing page became plain ugly, but that didn't matter, because "Signups are increasing!!" I'm not sure I'm following you here, so perhaps you'd care to elaborate? The GP critique was that it was perhaps just creating a problem elsewhere later on. I'm not seeing the similarity to your case where the change is cosmetic not functional. The issue of whitespace (padding) is subjective (see the conversat…

I think one problem is that a better design would move the button above the fold without ruining the spacing, and therefore achieve a better result with even higher lift, but someone focused on just the numbers wouldn't understand this. The fact that the A/B test has a big green number next to it doesn't mean you should stop iterating after one improvement.

Okay - but the design without padding converted better than the one with padding.

A/B tests don't give you the best possible choice of all choices. They just give you the better choice between A & B.

The business shouldn't delay rolling something out that increases conversions *significantly* because a better design *might* exist.

You can A/B test "better" designs in the future until one converts better.

Re: Removing stuff is never obvious yet often better

#149

Post by PaulHoule »

xorcist wrote: post #118
otherme123 wrote: post #115

Earlier quoted context omitted.

> Of course if you hide the fact that your product might cost a lot of money from your users, more of them will sign up The problem with their calculator was that the users introduced slightly wrong data, or misunderstand what means some metric, and suddenly a 1000x the real price was shown. Their dilemma was "how to fix those cases", and the solution was "get rid of the messy calculator". But they are not hidding a…

Let's not take a PR piece completely at face value. There's probably a bit of both, at the very least.

In my mind Pinecone is an exemplary example of modern "social media marketing" for a technology company.

They started on vector search at a time when RAG in its current form wasn't a thing; there were just a few search products based on vector search (like a document embedding-based search engine for patents that I whipped into shape to get in front of customers) and if you were going to use vector search you'd need to develop your own indexing system in house or just do a primitive full scan (sounds silly but it's a best-case scenario for full scan and vector indexes do not work as well as 1-d indexes)

They blogged frequently and consistently about the problem they were working on with heart, which I found fascinating because I'd done a lot of reading about the problem in the mid ought's. Thus Pinecone had a lot of visibility for me, although I don't know if I am really their market. (No budget for a cloud system, full scan is fine for my 5M document collection right now, I'd probably try FAISS if it wasn't.)

Today their blog looks more than it used to which makes it a little harder for me to point out how awesome their blog was in the beginning but this post is definitely the kind of post that they made when they were starting out. I'm sure it has been a big help in finding employees, customers and other allies.

Re: Removing stuff is never obvious yet often better

#150

Post by james_marks »

Reminds me of the advice that, if you need to join two mismatched pieces together, you have two options.

1)Add an adapter that’s customized on both ends, or 2) subtract the differences so they mesh directly.

Always look for opportunities to subtract, rather than add. Your system gets easier to understand over time as it becomes the purest representation of itself, instead of a collection of gap-fillers.

Post reply on HN