Hacker Newsnew | past | comments | ask | show | jobs | submit | alonmower's commentslogin

If you’re interested in this area I highly recommend “The Vital Question” by Nick Lane if you haven’t read it.

The TLDR of his theory is that life originated in alkaline hydrothermal vents on the ocean floor, where natural energy gradients could have driven primitive metabolic reactions before the development of DNA.

Book goes into a lot of layperson-accessible detail.


The necessity of higher quality data from vetted experts is why Mercor just raised at 10B


you could say the same thing about a search engine. if they keep an edge on brand or quality they can find ways of monetizing that attention


Honestly how google maintains a "moat" over other search engines could use a good business study. They've defied some pretty serious competitors there without an obvious lock in or anything.

(You can say default in various browsers and a phone OS and that's probably the main component but it's not clear changing that default would let Bing win or etc.)


Author here

I think it really depends. I agree that the prototypical pop something up in your face that forces you to interact with it and blocks your usage of the product make your product harder to use.

But stateful experiences don't inherently suffer from this problem. Checklists, embedded cards, context specific empty states, e.g. can all make products easier to use, and don't get in users' ways. And what someone should be shown should look different if they're in an empty product they need to setup, vs an experienced user that's very familiar with the product. Not treating these distinctly means you're compromising the experience for someone.

I do agree that keeping track of journey state in analytics tools, and getting that data to go to market teams are crucial too, but they won't make your product easier to use.


I gave up the moto when my wife and I started trying for a kid, and this is by far the thing I miss most about it. Instant mental clarity on demand. I bike a lot now but the lower stakes mean it's not quite the same.


We're taking the same developer-centric approach to onboarding at Dopt and this really is fundamentally different than the existing tools (Userflow, Pendo, Appcues, etc...).

I wrote up some longer thoughts on why their approach breaks down https://blog.dopt.com/dopt-vs-other-tools


Let's say a small farm or winery employees 20 employees and pays them an average of $50k a year. Holding three months of payroll alone will be over the FDIC limit, let alone other money they'll need to buffer all of their other expenses.


> Let's say a small farm or winery employees 20 employees and pays them an average of $50k a year

"Show your working" ... https://www.bls.gov/oes/current/oes452099.htm

> Holding three months of payroll [..]

Three months of payroll ... in cash?

I have two good friends who own and run wineries in France. Both of them are relatively successful, but neither of them have anywhere near 20 employees, for the simple reason that they can't afford to. The majority of the work is done by family members.


https://dopt.com

Project Description: We’re building a tool to design and run user state machines (we call these ‘flows’). It’s comprised of a shared canvas for modeling and versioning user flows, SDKs for instantiating those flows per user, and a platform to persist user flow state that handles migrating users between versions on the fly.

The SDK gives you hooks to manage state for each node (we call these ‘blocks’) and Dopt handles any side effects, transitioning all dependent blocks for you. Reactivity is also built in: those side effects on the user state graph, along with any others (e.g. updates to user properties or API invocations) are propagated in real time to the SDK.

We started Dopt because we’ve seen teams struggle when trying to build experiences that are contextual to what a user/workspace has done (e.g. product onboarding and education flows). Doing so requires modeling user state graphs in the DB, migrating the schema/data across versions of the graph, tying in product state to state outside of the product, and lots of back and forth with product and design.

What do you want to be tested: We're looking for more folks building with Dopt during our private beta. We're giving the product away for free during this period and cutting discounts for folks that build with us now once we go GA.

Contact: info@dopt.com (or you can sign up for the beta on the website and reply letting us know you found us on Hacker News to skip the line)


I’m building my own SaaS and am really interested in something that would help me create great onboarding. So I went to your website and honestly tried to understand your product. Instead of great onboarding your website has very complicated video, that I gave up on.

So maybe having a great onboarding on your own website would be a good way of showing that your product is great.


Thanks for the feedback, we're planning some larger updates to the website so helpful to hear!

We do have an interactive example gallery that we're building out for the reason you call out, would love any feedback you have on them: https://www.dopt.com/examples


One caution is that later stage private companies that raised big rounds at huge valuations will have a very hard time growing back into those valuations. Options granted have the potential to have high strike prices and limited to negative upside. If you’re getting RSUs it’s less of an issue but you may need to discount a bit from what they tell you they’re worth when you evaluate your offer.

They do have lots of cash though, so you can probably negotiate strong salaries.


We’re currently anchoring our messaging around onboarding as a use case. The experiences are highly stateful, but the product itself is a visual flow builder to model the state machines and SDKs that let you reference and manipulate that state while you build. We’re not living at the UI layer at all so while people can build tours with the product, it’s not limited to that.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: