Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
tagspace
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
5 ms
·
1.
▲
Embedded data analytics startup Embeddable raises €6 million from Open Ocean VC
(techcrunch.com)
1 points
by
tagspace
2y ago
|
0 comments
2.
▲
by
tagspace
2y ago
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
3.
▲
Embeddable: A developer toolkit for building fast interactive embedded analytics
(trevorio.notion.site)
11 points
by
tagspace
2y ago
|
1 comments
4.
▲
by
tagspace
3y ago
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
5.
▲
Ask Hn: Building in-app analytics for your app? We'd love to talk to you
(embeddable.com)
2 points
by
tagspace
3y ago
|
0 comments
6.
▲
by
tagspace
3y ago
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.
7.
▲
Ask HN: When building in-app reporting for your customers, what can go wrong?
3 points
by
tagspace
3y ago
|
6 comments
8.
▲
by
tagspace
4y ago
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 mea
9.
▲
by
tagspace
4y ago
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 creativ
10.
▲
by
tagspace
4y ago
> 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.
11.
▲
by
tagspace
4y ago
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
12.
▲
by
tagspace
4y ago
Totally agree. Wether something is a bug should definitely be decided by the team, not the customer.
13.
▲
by
tagspace
4y ago
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 decis
14.
▲
by
tagspace
4y ago
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.
15.
▲
by
tagspace
4y ago
Yeah - that's a super interesing point about bug fixing leading to engineers wanting to quit. Have you found a balance that works?
16.
▲
by
tagspace
4y ago
I believe it :D
17.
▲
by
tagspace
4y ago
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.
18.
▲
by
tagspace
4y ago
"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&#x
19.
▲
by
tagspace
4y ago
What do you mean by "ossify"? You think in practice there will always be bugs, so we will stop moving forwards?
20.
▲
Ask HN: What would happen if we prioritised all bugs over all new features?
42 points
by
tagspace
4y ago
|
74 comments
21.
▲
by
tagspace
4y ago
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 ta
22.
▲
by
tagspace
4y ago
Exactly. :)
23.
▲
by
tagspace
4y ago
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 s
24.
▲
by
tagspace
4y ago
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: - you've actually built something (not just an idea on a slide
25.
▲
by
tagspace
4y ago
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
26.
▲
by
tagspace
4y ago
Nice! We've had a lot of interested speakers, which is awesome.
27.
▲
by
tagspace
4y ago
Thanks for the inside scoop yaseer. And yeah, fingers crossed places like TechHub will thrive again.
28.
▲
by
tagspace
4y ago
Totally agree
29.
▲
by
tagspace
4y ago
Good point! Will see what we can do
30.
▲
by
tagspace
4y ago
Please do ;)
More ›