erader (u/erader) - Readit News

erader commented on Show HN: Micasa – track your house from the terminal micasa.dev... · Posted by u/cpcloud

fudged71 · 21 days ago

This is in line with my thinking, can you say more about how intent changes how you would use a system like this?

I had a really complex negotiation for car repairs (goodwill warranty, balancing a long list of repairs/recalls etc) which was pretty time sensitive. If I had already had my service record in a structured format along with the manufacturer's policies I feel like I could have responded with better preparation. Same for any other big maintenance items on the house, mortgage, insurance, etc.

And then there's the flip side--what do my policies and healthcare/loyalty plans cover that I'm not taking advantage of? What can be combined towards my goals etc.

erader · 20 days ago

For my initial system I'm not building full historical service history, insurance policies, etc. because it's a serious amount of scope on top of the core value prop, which is point-in-time "is this a good quote?". When I eventually do this, I'd need to do it proper with LLM + RAG, etc.

I do have the concept of an "asset" which could be a car, house, etc. and with enough basic info it's pretty easy for the LLM to cross reference common problems, or at least suggest questions that you should follow up on.

I'm leaving intent pretty free-form for now, the most friction I'm willing to add is 2 things:

- Basic enum preferences around budget and flexibility to help with prompting

- A claude code style "a few questions" follow up

Any additional form friction I think gets too complex.

It's funny, a lot of my research has been from subreddits for auto, homeownership, questions for people who work in trades, etc. Every time someone asks "is this quote fair", the response from the experts is almost always "But what do you want"

So in a time-sensitive repairs scenario, intent could "What get's my car safe to drive again for daily commute.... or for a long roadtrip". The output analysis could recommend which fixes are highest priority, where work could be split up, delayed etc.

erader commented on Show HN: Micasa – track your house from the terminal micasa.dev... · Posted by u/cpcloud

order-matters · 21 days ago

how do you handle the LLM hallucinations in analysis? I like it for data extraction but i never trust it to analyze anything

erader · 21 days ago

First, I've spent a ton of time becoming opinionated about a normalized data model that supports the product experience I'm trying to build. This applies both to the extraction (line items, warranty sections, vendors, etc.) and the analysis portion. The latter is imperfect, but aligns philosophically with what I'm willing to stand behind. For example

- building outputs for price fairness (based on publicly available labor data)

- scope match (is vendor over/under scoping user's intent)

- risk (vendor risk, timeline, price variability, etc.)

- value (some combination of price, service, longevity, etc.)

I don't get much hallucinations in my testing, but overall it's pretty complex pipeline since it is broken down into so many steps.

erader commented on Show HN: Micasa – track your house from the terminal micasa.dev... · Posted by u/cpcloud

fudged71 · 21 days ago

I think/hope the whole "home manager" category is going to take off soon.

On a cost basis, it no longer makes sense--practically--not to use visual/text/audio intelligence to manage such a large asset. We just don't have the user-friendly mass-market interfaces for it just yet.

It's possible to scan every manual, every insurance policy, ingest every local bylaw. It's possible to take a video of your home and transform it into a semantically segmented Gsplat of [nearly] everything you own. It's possible to do sensor fusion of all the outward facing cameras from your home. And obviously agents like OpenClaw can decide what to do with all of this (inventory, security, optimization, etc).

erader · 21 days ago

I've been working on something like this the last few months specifically around service quote analysis (repairs, construction, hvac, auto, etc.) and it's really cool. I think LLM analysis is the way to go because the amount of complexity is absolutely staggering - just to start the difference in quality and information available on a quote is drastically different between vendors within the SAME vertical. Then to do actual do analysis on local laws, the details of your property (not just photos/videos, but zoning and lot details), vendor analysis, etc.

On top of it all, the most important thing to consider is intent -> An emergency plumbing visit is often very different than a proactive upgrade.

edit: spelling

erader commented on Ask HN: Who is hiring? (August 2020) · Posted by u/whoishiring

elbear · 6 years ago

Clicking on the URL of your careers page gives me a Page Gone (Error 410).

erader · 6 years ago

We actually recently changed our jobs page! Here's the right link: https://jobs.lever.co/coalitioninc

erader commented on Managing product requests from customer-facing teams brettcvz.com/posts/53-man... · Posted by u/brettcvz

brettcvz · 6 years ago

Totally agree with the “yes and” approach of firehose plus top two - I haven’t had a chance to update the post yet, but responded to similar feedback here: https://news.ycombinator.com/item?id=21971011

erader · 6 years ago

Cool! Another weird thing I've noticed when feature requests are capped for customer teams, is that customer teams will "game" the system.

At scale, customer facing ICs will do things to benefit them personally. It's not a bad thing, it's just human. Sales people do what they need to get quota, Support want to keep their ticket backlog down and CSAT high, etc.

If you receive all customer facing feedback, you can make the final prioritization call on your own. If requests have been filtered too much before they reach you, the priority must be taken with a grain of salt.

erader commented on Managing product requests from customer-facing teams brettcvz.com/posts/53-man... · Posted by u/brettcvz

erader · 6 years ago

As a PM that has started my career in Support/Success... I don't think I could ever advocate a strict two-request limit.

Customers (and customer teams) are a non-stop firehose of feature requests. It's important for the product team to hear all these requests, mostly so they can be understood. It's tedious work, but I do it with the intention of looking for patterns and having a pulse on the customers. You might be surprised by what you find, especially how many feature requests are actually different solutions to 1 larger problem.

My team does this using ProductBoard (https://www.productboard.com/) to synthesize all incoming feature requests on a weekly basis. We sit for 30 minutes as a team to go through direct requests, lost sales opps, etc.. This weekly work pays dividends when it comes time to prioritize features for the next quarter/year, etc.

Customer teams can feel empowered when they are given the tools/opportunity to prioritize things on their own, but the huge downside is that they feel silenced on a large majority of things they can't tell you (i.e. the "lower" priority" requests). This can really eat away at the morale of customer teams that feel they can't share their customer stories with you. When they hear feature requests from customers that they know are low-priority, it feels horrible to tell a customer it won't even be looked at by Product (it's even worse to lie).

I'd recommend a system where all feedback is shared, but only 2-4 feature requests are "voted" for officially by each customer-facing team.

erader commented on Be Wary of Solving a Small, Rare Problem [video] blog.ycombinator.com/be-w... · Posted by u/lainon

tensor · 8 years ago

As an aside, I think companies should take "problem requests" not feature requests. A feature requests implies a solution, and letting your customers be your product designer leads to generally messy and poorly designed products.

So rather than submitting "I'd like the app to do Y", it would be amazing if customers instead submitted "I'm trying to solve problem X and having trouble." Maybe Y is a good solution for X, but maybe Z is too and Z wasn't asked for even though it might be what you need.

erader · 8 years ago

This is exactly how our team likes to operate :)

Taking only 'requests' leads to a whole range of potential problems: - Feature bloat with random one-off buttons and gizmos - Product teams getting in the habit of ignoring requests if they know that most don't quite fit - Really complex products (both for customers and internal teams to understand/troubleshoot) - Unclear roadmaps - Wasted time. For example, I had a request to build a notification-silencer for specific executives at a company. I recommended that the executive set up email filters instead

erader commented on Be Wary of Solving a Small, Rare Problem [video] blog.ycombinator.com/be-w... · Posted by u/lainon

newusertoday · 8 years ago

can you share the features that are lacking in intercom? and would you be willing to pay more for them? if yes how much i.e $/month

erader · 8 years ago

My list is too long to share, but let me give you a very simple example.

On most chat platforms, the widget displays an "mail" button or something similar that allows the visitor to send the transcript to themselves for reference later on.

Intercom does not have this, and agents don't the ability to quickly send transcripts either. Our team literally has to copy/paste the transcript into a new Zendesk ticket to send it.

Intercom's philosophy dictates that a 'conversation' is an ongoing thing that happens anywhere: in-app if the user is in session or via email once the user's browser session your website has stopped.

Their philosophy ignores the very clear pattern of visitors treating the intercom widget like a "normal" chat widget (which many have come to expect).

The 2 ways to perceive this are: - Adding this feature adds value for me and I should pay for it - Adding this feature bring Intercom to parity with customer expectations, and should be included in the price. Not having it is an unnecessary blocker.

I strongly believe in the second one.

erader commented on Be Wary of Solving a Small, Rare Problem [video] blog.ycombinator.com/be-w... · Posted by u/lainon

erader · 8 years ago

I totally agree with that sentiment, but I find it hard to swallow coming from Intercom.

Even as their customer, I find that they don't like to solve any problem that doesn't fit within their 'philosophy'. I've submitted countless feature requests to no avail, and clearly they've left their customer facing teams high & dry. I feel bad for their support staff and success teams that have been completely disjointed from product teams.

Intercom is my go-to example of a product that tried to re-invent the wheel, but only came up with half of a wheel. They need to finish it. They need to help customers solve the problems they are experiencing, which continue to exist because some missing features don't fit the 'Intercom philosophy'.

Generally speaking for any product team, just make sure you've completed your due diligence of making sure a problem is in fact rare and small. You'll often be surprised at what you uncover.

erader commented on As a solo developer, I decided to offer phone support plumshell.com/2017/11/30/... · Posted by u/NonUmemoto

b3lvedere · 8 years ago

"At the end of the day, just know that we're all people on one team (albeit with very different daily responsibilities). Respect each other's time and needs, and the rest will fall into place."

I do a lot of helpdesk. I've found out most of the time there is a huge difference in information availability between support desk and the rest of the company. Support people spend a ton of time and frustration finding out what the hell a client is talking about, who promised them things and where or what the hell the service level agreement is.

I made a lot of (account) managers very very angry by stating well written documentation and procedures should available to the entire support team. It should be a milestone of EVERY project or else there is NO finished project. People should not be held responsible because of lack of supplied information. Especially when they've asked for it a gazillion times.

This is one of the reason these teams hate each other so much in big companies.

erader · 8 years ago

Totally. It should be in the GTM checklist for every product/feature