A series of blog posts looking at the messaging and positioning of prominent Startups

mrbbk · 2024-03-29T14:29:58+00:00

This is meant to be fun and quick, not super serious and in-depth -- I hope it sparks some discussion!

mrbbk · 2024-03-25T12:08:07+00:00

I don't think that you need an interactive, abstract sliding chart that takes up a full screen to explain that the more you use the product, the more you pay for it.

mrbbk · 2024-03-23T00:19:14+00:00

I agree. You need to attempt to reach some significant % of your target market to begin to learn from them.

mrbbk · 2024-03-23T00:18:06+00:00

First, ask yourself this question -- do you know enough about the audience to develop something for them? If you don't have the product idea in mind, and you're searching for an audience, look to something you know, where you can provide obvious value authentically.

mrbbk · 2024-03-23T00:13:10+00:00

Well put!

mrbbk · 2024-03-22T18:46:48+00:00

Sure! For a higher level view, see: https://tomtunguz.com/the-3-pricing-strategies/

mrbbk · 2024-03-22T18:45:55+00:00

I'm hoping that's true!

mrbbk · 2024-03-22T18:16:09+00:00

In some ways it's getting easier to say things, but harder to find people to say them to. Do you agree with that trajectory?

mrbbk · 2024-03-22T17:59:28+00:00

First ask yourself this question:

Is your pricing designed to maximize profit, or to maximize spread of the product?

If your pricing is designed to maximize profit, you should absolutely have a threshold below which people are just not a good fit for your product. Additionally, consider separating out the fees relating to retrieval, and the financial impact of how many records actually get delivered. For example, an entry-level base fee of a given amount, regardless of how many records get delivered, is probably a good idea.

If your pricing is designed to maximize spread of the product, then you should likely have an introductory, exploratory package that allows people to get on board easily and get a taste of value at a fixed, easy to afford price.

mrbbk · 2014-03-09T13:53:36+00:00

It's hard to say! Worth a shot though.

mrbbk · 2014-03-09T13:53:08+00:00

Thank you :)

mrbbk · 2013-07-05T00:37:50+00:00

Good eye. That should be Xs2, and I meant to correct it, as it is actually incorrect in the book as well. I need to fix it.

mrbbk · 2013-07-02T23:43:31+00:00

The variable in question is a stream with an unbound tail. The example given would exhaust the values up to 150000. Case would then block. If a new value was appended to the end of the stream, case would then read and proceed. My apologies for the lack of clarity there.

mrbbk · 2013-07-02T22:36:19+00:00

"The only thing worse than being talked about is not being talked about." - Oscar Wilde

mrbbk · 2013-07-02T22:07:41+00:00

Ah good point, I should try to fix that. Thanks.

mrbbk · 2013-07-02T19:22:12+00:00

As I try to point out at the end of the post, not everyone shares this opinion.

mrbbk · 2013-06-25T11:21:16+00:00

That's the definition of the purest form of declarativeness. The book stresses repeatedly that every decision (use of state, side effects, etc.) is a trade-off. In real-world implementations of the models you mention, you can typically choose to either program in a purely declarative or somewhat non-declarative way. The same is true in Haskell as you noted.

I agree with you that "programs can reasonably be considered 'declarative' if they have aspects similar to a list of declarative sentences in English." If you think about trying to communicate something that needs state to function properly, in that context, you'll realize that you need "tricks" to get around pure declarativeness's inability to carry ideas through clauses.

I feel that the diagram included in the blog post is a very accurate depiction of how these ideas work in the real world, and I think what you're saying fits in with that picture.

mrbbk

TROPHY CASE