tagspace

Hey all. We're super excited to introduce our new platform, Embeddable: a developer toolkit for building fast, interactive customer-facing analytics directly into your product.

It generates a no-code dashboard builder for you, powered by the components and data models defined in your code repository.

I've linked to a video showing how to use the SDK, no-code builder and how to build a dashboard.

Happy to try and answer any questions you might have.

Biggest finding for us has been that no matter how many charts / filters / options / etc. we give to our users, they always want something more.

Answers don't just lead to Eureka moments, they lead to follow up questions and follow up questions.

Not a complaint - it's actually great. Just an observation (and a challenge)

Thanks @warrenm. That makes a lot of sense. The problem is that that feels like we'll have to throw away the "looks like a nicely integrated part of our platform' requirement.

This is actually exactly what we had in mind. Except that P2 gets put in a "won't fix" bucket.

- P0 means drop what you're doing and fix it now

- P1 means fix after you've finished what you're doing

- P2 means "won't fix" (but keep a note of it in case we ever get to that perfect situation where we have more time than features to build ;))

Really good point about bug fixing affecting engineer morale. Super important.

One (arguably positive) side-effect I'm wondering might be possible is that: if bugs are always prioritised first .... and engineers are often very creative at solving problems .... will they perhaps come up with creative ways to reduce bugs in the first place?

Or, it might go all wrong -> and we create a dangerous culture of "swallow that exception" :D

> On a sufficiently complex product it is impossible to fix all known bugs

You really think so?

Surely it's just a matter of picking a sufficiently high bar for "will fix" and then focusing some time on it.

I like the curve idea. Makes sense.

When customers aren't signing up because of lacking feature -> build features. When customers are churning because of bugs -> fix bugs. Else -> somewhere in the middle

Totally agree. Wether something is a bug should definitely be decided by the team, not the customer.

Your point on intellectual honesty really resonates.

I personally like the idea that for every bug you either: a) fix it with highest priority, or b) mark it as "won't fix".

I think this would really force you to make a decision on a bug, rather than adding it to some never ending list of lists.

If a bug is worth fixing, it will come up again

That's a really good point. If your userbase is feels listened to (which is admittedly easier in B2B than B2C) then these decisions become much easier.

Yeah - that's a super interesing point about bug fixing leading to engineers wanting to quit.

Have you found a balance that works?

I believe it :D

This is a nice way to put it. Our platform is already pretty mature, and customers are happy.

Naturally, the wishlist of new features never ceases to shrink ... but the stability of the existing platform is what people really appreciate.

"in practice this just means 3 or 4 levels of bugs that will never get fixed" - this is so spot on! This is exactly what we were thinking: realistically, if we don't fix it now, it will never actually get fixed.

So, if it's important enough to fix, why not fix it now.

What do you mean by "ossify"? You think in practice there will always be bugs, so we will stop moving forwards?

We use a number of 3rd party APIs, and the problem we hit was knowing which to trust, which were reliable and which could be counted on.

I'm obviously not talking about your Googles / Twilios / Auth0s / etc. I'm talking about the longer tail of services that we don't want to build ourselves, but that there isn't instantly a big name service that provides it.

We would try one or two, and then find that they would work great in testing, but when you put any kind of load on them then they would regularly fall down. Similarly, when you reach out for help - while you're in the buying phase, they're very responsive - but as soon as you need support, you're looking at days not hours for a reply.

Exactly. :)

Perhaps in-person was the wrong word. "Present" is perhaps closer to what I meant. We want our presenters to have an audience. We want audience participation / questions / feedback. We want to create a buzz. ;)

Not saying that YC's format doesn't achieve that. It's just different.

But either way - totally see your point on posting it online afterwards.

Great question!

We have been blown away by the amount of interest, today alone, in presenting at next month's event.

We think that the most important things should be:

- they've actually built something (not just an idea on a slide deck)

- they can demo it (we want to see behind the curtain)

- what they're doing is uniquely interesting (not just another ride sharing app)

- the problem they're solving is also understandable by a non-technical audience

- and, of course: their team are passionately bursting with excitement for what they're building :)

Apart from that, we'd ideally like to find a way for anybody to speak.

Nice!

We may do for future events ... but we really want this event to have a community feel, so being there in person is what it's all about :D

Nice! We've had a lot of interested speakers, which is awesome.

Thanks for the inside scoop yaseer. And yeah, fingers crossed places like TechHub will thrive again.

Totally agree

Good point! Will see what we can do

Please do ;)