- we use Zulip, so it would be neat to see an integration
- this strikes me more as a feature than as an add-on per-user. The value of this is it makes it easier to expand the scope of decision making because of facilitating a process. Yet the pricing disincentives adding each additional decision maker and limiting the users to the core team. That seems in conflict. I would rather pay a flat fee per month.
- the above may indicate a lower revenue ceiling, but also I could easily see slack themselves adding something like this, or a FOSS version for polling, so I think it would make sense to keep the pricing affordable for everyone
Zulip is a really nice tool and a favorite of mine too. It's already on the list for tools we need an integration for.
Pricing is really hard. We aimed to make it as transparent as possible and tried to make it more attractive by only billing for active users. Maybe we could enable something like 'confidants' who can view decisions but aren't billed? Though if someone doesn't really interact with the app but just looks at decisions they aren't billed anyway. Really difficult, or maybe I just don't see it (yet)? Maybe you can elaborate what you would like to see there?
- bands per users ($free from 0-10 people, $50 from 10-20, $500 from 20-100...)
Yes, and this does imply that you will make less per user than if you charged each individual user per the pricing on your website. The other half of my comment is that this tool is a convenience thing, as an add-on feature to an existing chat tool and should be priced very low. The low price will disincentivize people from doing alternatives (such as any type of free poll, or building it themselves/FOSS), so the lower prices will end up in a higher value for you overall.
I've been thinking of how to solve the "decision history" of a business being lost and this looks great! One question I have though is how do you propose people find these decision log entries a year or two from now?
Currently decisions can be tagged and you can search through them, but we’re thinking about integrations to other tools, like Asana, or filtering and clustering options, as well as UI improvements. We’re aware that the current version is more of a refined MVP but we won’t stop improving.
How? I read through few other pages and don't see this described.
On "How It Works"[0], everything after the first "step 3" seems mostly worthless for every team I've ever worked on and feels like it's more like something that isn't for me? Like who gets something out of those when it's a product (that heavily pushes their slack integration) for "teams" to record decisions?
> How? I read through few other pages and don't see this described.
We encrypt the important fields in the DB, besides having encryption at rest. Of course, with enough effort we could see the content of decisions, but we would need to take the additional effort. We try to separate us as much as possible from our users data. Maybe we should clarify that on the home page.
on your second point:
I think we still have to tune our communication. Of course, maybe it just isn't something for you, hard to tell, depends on your existing decision taking process in your team and on the projects you work on. Can you elaborate on why it's not for you? Maybe we miss out on scenarios and could improve our app there, we don't consider it 'done'.
We hope that Loqbooq can help with long running projects where (software) design decisions but also management decisions get lost over time. We also hope Loqbooq helps if problems arise between co-working parties in projects.
Reads to me it's impossible for you to see them, as if you used client-side encryption of some sort. It's good to hear it's well protected as is, but I'd reword it.
For the later messaging, I'm just trying to think about what situations one would be in that this would need to be immutable and verifiable in this way. Like something would have had to have gone very very wrong so having that be a big part of your sell feels vaguely blockchainy/scammy (to me). Keep it sure, but make it a smaller part of your pitch and focus on the common path of helping a long-lived team documenting and referencing decisions, which was what I was mostly looking for.
All the strategic decisions I’ve seen lately, management doesn’t want anyone to know how they came to those conclusions. They want that kind of information to have never been logged, or to be buried as deeply as possible.
They don’t want to be embarrassed six months in the future when people find out how that decision was made.
I don’t know how you can solve that part of the problem.
It is really a hard problem. Sadly I also don't have a good answer. If management is this dysfunctional, at least the team can maybe document how they do sane decisions and reasoning?
at $enterprise-dayjob decisions like this (ADRs etc) are generally recorded in the company wiki (confluence). pricing per user of loqbooq seems comparable to pricing per user of confluence.
> Whenever you leave (or get kicked out of) a Loq, Loqbooq will automatically email you a full PDF export of the current decision Loq.
Oh wow, I am very much not in the target market for this service.
Would you consider automatically sending the export as an anti-feature, and if so why? For context, we added this to help with disagreements were one party kick out another party in a dispute. So afterwords they can reach agreement with a common basis.
I'd guess that if your dispute has reached the level of kicking each other collaboration tools, then I would not be the target market either, in the sense that this isn't a common enough use case for me, that it would warrant optimizing for it. A workplace like that is just not very healthy.
Sure, conflicts happen all the time, and I guess it is good to be able to handle that, too. But it feels a bit odd to include this in the marketing material as a common case.
If I was marketing I would try to find a way to draw attention to this feature in a more subtle way.
The thing that you are trying to sell is that "all parties have access to verified decisions at all times", right? Maybe there is a way to word it that does not end up associating "loqbooq" with "disputes and projects falling apart".
While I am at it: I think I understand the technical background of Points 1,2,3,4,5 of "In Case of Dispute", but it's worded very technically. Maybe there is a way of describing the benefits of a (semi-)distributed verified log more high-level and then add an additional section "How it works under the hood".
i was thinking about scenario where all parties involved in decision are employees or contractors working on some internal project for a single enterprise company, and decision log is being used to record project decisions.
in that case, enterprise company is the one paying the bill for loqbooq subscription, so enterprise would want to set the policy for accessing data / onboarding / offboarding. they'd want SSO integration for access control, and if SSO integration said "this user no longer has an account; access denied" then the enterprise would want loqbooq to deny access and not email out a copy of internal enterprise data.
basically: if there's a disagreement between one or more parties involved in a project where loqbooq is being used, but only one of the parties is the customer paying loqbooq the monthly subscription, so wouldn't that paying customer want loqbooq do do the thing that is most in their interest?
Enterprise might think through scenarios like:
* "what if one of our contractors or employees foolishly/accidentally dumps customer PII into external loqbooq.app SaaS outside of our datacentres? how do we limit & do damage control over data breach?"
* what if we believe that some of our employees are trying to start up a new business in competition with us, and might try to use our proprietary information to do so? (product roadmaps ; architecture docs ; lists of customers & suppliers ; ...)
In both scenarios they may want a mechanism that gives company administrators a quick and reliable way to terminate user access to loqbooq and limit risk of further information leaks.
We built Loqbooq to address some things around documentation in longer running projects. Decisions and their rationale, taken at the beginning of a project, often get lost and then discussed over and over again. Also it's hard to pivot in a project, if nobody knows why certain decisions were taken in the first place (think software design). Finally, it's always good to have buy-in from (non-technical) stakeholders.
We hope that Loqbooq can add to better documentation and decision making.
1. the pricing is almost as expensive as Slack. May be a free tier or longer trial?
2. How does one discover past decisions? Some pointers from documentation? Some easy permanent URL’s? How do we ammend/link (new decisions taken on old questions, given new marker conditions)
2. how do you suggest we prevent blaming/pointing-fingers about bad decisions? I understand it is not a tooling problem, but just curious if you had any ideas around it.
1. Pricing is hard, this is our first best guess. We also thought about extending the trial. We're also thinking about a less expensive personal trial.
2. The App is basically organized in a way that a 'Organization' has 'Loqs' (projects) where you save 'Decisions'. All taken (and agreed on) decisions are then displayed in the Loqs and can be linked by loqbooq.app/organization-name/loq-name/#anchor-num.
It's also possible to make succeeding decisions that link back to their preceding, basically to amend older ones.
3. We hope that if people take decisions together and decisions are entered with multiple deciders at once, that this would help with finger-pointing. But I agree, this is a problem.
Simple unalterable "decision log" would be:
1)set up an email alias decisionlog@ . It mails to a folder people can read. This is the unalterable part. Digital signatures etc are not needed unless you're worried about your employees pwning your mail server.
2)Post emails in that folder to slack using one of the solutions here https://slack.com/intl/en-gb/help/articles/206819278-Send-em... . Or don't, you know. Not everything has to be in slack.
3)Get beer. You're done
In my experience much of the time when people say they need a knowledge hub/decision log/wiki etc those things are available but underused or not useful. The challenge is that when corporate knowledge gets past a certain threshold the amount of time needed to catch up on parts you've missed and the tendency for the usefulness of those information resources to decay over time comes to dominate.
However you store your decision log, in a year you'll have hundreds or thousands of decisions in the log and entropy will rapidly set in.
I hope it's a bit more than that. With emails you could run in the problem that sometimes not everyone who should be involved gets cc-ed. Not everyone maybe answers the mail right away and it's difficult to keep an overview who decided or agreed already. It's also hard to remind people individually and automatically. Lastly, searching through long email threads is also sub-optimal.
We hope Loqbooq helps with these problems, especially for teams that use Slack (and later other platforms)
Here's my feedback
- we use Zulip, so it would be neat to see an integration
- this strikes me more as a feature than as an add-on per-user. The value of this is it makes it easier to expand the scope of decision making because of facilitating a process. Yet the pricing disincentives adding each additional decision maker and limiting the users to the core team. That seems in conflict. I would rather pay a flat fee per month.
- the above may indicate a lower revenue ceiling, but also I could easily see slack themselves adding something like this, or a FOSS version for polling, so I think it would make sense to keep the pricing affordable for everyone