HN user

maartn

177 karma
Posts5
Comments37
View on HN

Microsoft did a very interesting research about this amongst 60k+ employees. Read it to find out why serendipity is a good thing and hardening already existing relationships is not good for the whole:

“Furthermore, the shift to firm-wide remote work caused employees to spend a greater share of their collaboration time with their stronger ties, which are better suited to information transfer, and a smaller share of their time with weak ties, which are more likely to provide access to new information.”

https://www.nature.com/articles/s41562-021-01196-4

I don’t know who runs this but it’s definitely incomplete. Too bad the “European alternative” to webchat doesn’t even work on mobile. Maybe that’s the reason why it’s so incomplete

1 Work with a local party during development. We worked with a local party that co-owns a factory in CN. Will not do it again. Even they had trouble communicating the right information and requirements. It took at least 6 to 8 weeks before we had a next iteration in our hands. We had to do about 8 iterations before the product was OK and 12 before it was exactly right... We will develop our next product locally and only when the mould tooling is finished will we possibly look for remote manufacturing. 2 Have non-manufacturer eyes on the floor in the factory do checks during production. 3 Request certification of the materials and coloring.

Thanks for all your answers. It really helped to create a framework of what legal mumbo to put where.

We've decided on the following stack:

- General Terms of Service. This will describe what benefits customers can expect from us and by which general means we deliver this e.g. our core service but also support, the amount of effort, etc; what requirements customers need to fulfill before we can deliver our service (like a working internet connection), that customers may only use our service for what it is meant for and shouldn't try to hack our shit; that customers will have an obligation to pay for these deliverables and how long we are willing to wait for payment, what we do when they don't pay and other nasty stuff; How we communicate, where you can find pricing information and what happens in case of disruptions and calamities, what liabilities we accept and how we promise to handle complaints and disputes; other stuff that needs to be said like how we handle privacy sensitive data and which legal jurisdiction applies.

- Terms of service concerning generics for a certain type of business model. This can be quite short and wil lay on top of the general TOS. E.g. in case of a subscription model, how subscriptions can generally be started, how we prolong them and how customers can cancel. Which requirements a customer should fulfill before a subscription can be delivered. (like a working internet-connection) Where to find the equipment that can be used to receive our service.

- Customizable customer contracts for different target markets and business models. Again these lay on top of the business model TOS which lays on top of the general TOS so this can be really short for a simple contract and expanded at will.

I'm convinced this is a very workable method for us and will give us the flexibility that we need in this phase while still adhering to our lawyers advise.

jŭs′tə-fī″: To demonstrate or prove to be just, right, or valid. (I guess you're going for "valid") ;-)

Spoiler: We're naive and want to make the world better! (yes, I've seen all Black Mirror episodes AND we have weekly drinks where we think up scenario's where our company is the villain) But we need to protect our business not swindle our early customers.

Thanks. It's not so much the TOS (should've phrased it better) but more the contracts. We're combining hardware with a software service and are experimenting with one-off sales with life-time (basic) service, premium service subscriptions, no-sale just subscriptions, deposit + subscription, etcetera. There are things, like the obligation to return the hardware at the end of a subscription, that we now have in the TOS. But if we want to experiment further we might need to add the obligations of every new business model in the TOS. Thanks to all the comments here I now understand this should not be in there but in the contract. This is exactly one of those "best practices" I'm looking for!

Thanks. You're right, our TOS should be more resilient than this. With "change routes" I actually mean "experiment with business models" and maybe some directional adjustments.

It's the "overlapping bands of probabilities" (sounds like a Boards of Canada album) that seems very hard to put in black and white...

I can read and relate to your frustration. But I'm convinced that a business is not solely made of fantastic software. Good people tend to earn good money. And if they want to spend it on their partner, that's not my business.

I've been in a situation where a couple of early clients were able to dictate quite a bit of the business due to early contracts. We do not want to end up in that spot.

So I'm looking for best practices to find a balance between "just trust me" and your scenario.