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.

It may be worth investing your time in skinning/theming whatever reporting/search tool you decide to use :)

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.

We had a P0 bug which caused unplanned device reboots in the field with unclear cause. It is still open, 3 years since first detection. And it looks like it will be open until device end of life. We have a mitigation for which affects performance, and that's about it. It was tracked down to deep inside Linux kernel and some firmware interactions and no amount of work produced a fix for it. And that was a mission critical bug, which was pushed by the biggest and super important customer (and others too).

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.