This is exactly correct. Private blockchains create efficiency between large institutions like JP Morgan and other banks who are constantly moving large volumes of money around by eliminating the traditional processes in place required to move that money. A private blockchain is essentially a shared database (distributed ledger) used by an arbitrary number of private institutions, each of whom has an interest in participating to reap efficiency gains by using a shared database that they can trust, more than they would trust a traditional database owned by a single party. It's not game changing innovation in the same way that crypto futurists think of Bitcoin as a new type of decentralized money, it's incremental efficiency for existing processes. It's more accurate to think about this as blockchain technology for JP Morgan than as cryptocurrency in the sense that Bitcoin is an application of blockchain technology. JPM coin is not like Bitcoin, or ripple for that matter.
The important thing to understand here is that JP Morgan thinks about blockchain technology completely differently than libertarian futurists. Blockchain is not a movement for them - it's a technology that reduces friction for things they are already doing.
> it's a technology that reduces friction for things they are already doing.
And there lies the rub, because as far as I can tell, this particular (and no particular) blockchain implementation does not in fact reduce any friction for things they are already doing.
I know people who have worked in this space (fintech permissioned blockchain). Although this was my initial reaction, they tell a different story. One angle to that is along the lines of "you wouldn't believe how bad the thing they use now is".
This is the aveneue of questioning I'd really like to see more detailed discussion on. [Disclosure: I'm agnostic on the potential of blockchain]
Does TPS increase non-trivially in a private chain vs a public chain? If not, will a private chain's TPS at least substantially outpace the TPS of, say, Ethereum within 3-5 years? That is, will JPM's private chain reach 100, or 1k, 10k, 100k, etc TPS?
Assuming TPS reaches a sufficiently high-level (whatever that could be), would a private chain require fewer sysadmin/engineering/etc. folk, compared to what the DTCC model requires?
Does a semi-private chain (where JPM allows other partners or competitors to plug-in) have a faster on-ramp? That is, would it be faster to plug players in than a traditional solution?
Is there a cost reduction somewhere within the audit process? Other processes?
I have these types of questions, but it is difficult to find much substantive discussion on them. Typically, answers are Yes or No, but with little to no detailed explanation as to why.
Thanks for this comment. I think you articulated the thought process that this post aims to speak to beautifully. Builders do want to build, and finding an audience first and doing the type of tedious customer development work described in this post IS an impediment to building, which is precisely the point I wanted to make.
Assuming that the goal of building a product is to ultimately generate revenue, having a temporary impediment between conceptualizing a product idea and building the product is a good thing. This impediment allows for the builder to pause and objectively scrutinize his own idea, using feedback from potential customers as data about the extent to which the product hypothesis is correct.
You're right that stagnation is the worst outcome. And the inverse of stagnation is momentum, which will exist to the extent that people want what we're making for them, something that can be determined in advance of building simply by talking to potential users and customers.
I'll also add here that the process mentioned in this post in no way inhibits the type of creative and inspired thinking that developers use to envision game-changing products. It's quite the opposite - rigorous and merciless scrutiny of our own ideas is the distillation process that allows us to refine our ideas into their essence, then confidently build things with conviction, and be right.
So to summarize (for my own understanding)... It's fine to want to build something first. However, if you want it to be financially profitable in a big scope of impact, you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.
Yes, that is my opinion. And if it's possible to build something minimal that helps demo or describe the product to users, it's totally reasonable to build that thing quickly and take it to customers for feedback.
The pitfall to avoid is investing large amounts of time, energy, and money building products in a vacuum based on assumptions about what people want and will pay for. I've heard this referred to as committing "assume-icide."
> you have a higher chance by plotting it out and then executing, than accidentally stumbling upon a perfect business model for your completed product.
You have a higher chance of stumbling upon a perfect business model by speaking to the customers before / during product design.
Thanks for the honest feedback. You are definitely correct that there are many successful projects and businesses that did not start with a clear sense that people would use or buy their products. But there are a disproportionately large number of projects and businesses that have failed, precisely because they did not have a clear sense that people wanted what they were making and would pay for it.
Also, this post isn't saying that builders shouldn't begin with a strong, fundamental conviction about how things should be dramatically different. I, as the author, would actually argue the exact opposite. The point I'm making is that once we have our convictions, we should test and measure the extent to which those convictions are correct before investing large amounts of time, money, and energy into productizing them.
Lastly, the point about asking questions and then listening to customer feedback would only result in building minimally better products if the product hypothesis we start with is itself unimaginative. But that hypothesis can be literally anything. Customer feedback simply teaches us if market demand lines up with our assumptions about market demand.
A "Hobby" project turning into a business is a rarity. It comes down to expectations of returns.
If you want a business, a monetize-able product, you have to think about sales. The observation that majority of Software start-ups fail to avoid the mistake #1 from this article is accurate. And majority of Software start-ups start with an expectation of monitory returns.
If the expectation is a personal sense of fulfillment, anything other than a business for that matter, then what you are creating becomes more of an art than a product. There is a chance you might earn from it, but it is slim.
I think this is a smart strategy, and is essentially using marketing in the same way that this post suggests using sales, to gauge customer interest in a potential product. The extent to which manual sales outreach or the kind of marketing technique described here should be used likely depends on the kind of product in question. B2B products with higher contract prices and a smaller number of total potential customers will likely require a sales strategy, where B2C products with lots of users and lower contract values may be better served with this kind of marketing tactic.
Great point, though! This is an important topic to consider with marketing and sales strategy development. Thanks for the comment.
I would definitely suggest being straightforward and honest with the potential customers you're talking to. And ideally, it would be better to have a MVP you can demo than nothing, but the main point here is that talking to potential customers before building anything is a better strategy than building a product and then talking to customers.
If you talk to a bunch of potential customers about a product idea and discover that there is demand for the product, then building a MVP that you can demo would be a logical next step. And if the MVP is something you can build quickly, then it probably makes sense to do this sooner than later.
The trap to avoid here is building products in a vacuum, based on assumptions about what people want and will pay for. Doing the customer development (pre-sales) work to prove, or disprove, customer demand for a product before building the product is wise.
> “If you talk to a bunch of potential customers about a product idea and discover that there is demand for the product, then building a MVP that you can demo would be a logical next step. And if the MVP is something you can build quickly, then it probably makes sense to do this sooner than later.”
Sales to Engineering Managers:
Alright team, we’ve talked with a lot of customers and realized there is a huge demand for this thing called a perpetual motion machine. Let’s try to get a prototype built for the client on-site next week, ok?
Engineering Managers to Engineers:
Alright everyone, we scoped out this perpetual motion machine into 3 Jira tickets. The first ticket is 3 unitless Fibonacci numbers of work, to create the base machine we’re talking about here. The next ticket is another 3 units to have someone mock-up the motion part, not sure exactly what they want here but maybe just put an RC car underneath of the machine from the first ticket? Finally we saw “perpetual” in the request from sales and that really sounded like a time sink so we pushed back. We’re going to time box this one and call it a 2-pointer. We’re thinking don’t spend more than a few hours on the perpetual part. Let’s do it everyone!
Engineers to recruiters:
The job just isn’t allowing me to fulfill the technical goals I want to pursue.
Recruiters to engineers:
I’ve got a hot new start-up you’d be great for. They only pay 60% of market rates but they totally need someone who can build out their entirely unvetted vision of what products to sell!
You should have really spent the time it took you to type in this over-the-top response to read the article with a bit more sympathy instead. It's not necessary to solve unsolvable technical challenges to make something that helps people.
Why do you think my comments did not already account for that? The article claims that software engineers make the mistake of building before they sell, and advises an aggressive form of selling before building instead.
But that advice directly means to skip engineering due diligence (which very often requires building before you sell). It doesn’t matter if the person implementing the advice would be an engineer or a sales person or anyone else.
Your comment comes off as if it is supposed to glibly (and I think also rudely) undermine what I wrote, but in fact I think you didn’t understand what I wrote, and you seem to suggest that it would be impossible for an engineer (using the article’s advice) to fail to consult an engineering estimate of technical feasibility prior to selling something.
Having a high degree of confidence that you are capable of building what you are selling is a given.
Nobody reading this is building anything resembling a perpetual motion machine. Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.
Your comment is plain old reductio ad absurdum. It’s not clever.
Writers are entitled to favor conciseness over having to pre-empt any fallacious dismissal they’ll get from whichever random person on the internet needs to entertain themselves that day.
> “Having a high degree of confidence that you are capable of building what you are selling is a given.”
No, it is emphatically not a given. Not in the context of some new CRUD tool. Not in the context of latest & greatest self-driving cars. Absolutely not.
> “Pretty much everyone in this post’s intended audience is building some combination of a database and a bunch of web forms and tables to undertake a routine business process.”
You’re just simply extremely wrong about this. Even internally to a large company you often have projects spun up for face detection, natural language processing, complex workflow management tools, adtech tools, embedded systems, robotics, medical devices, systems dealing with personally identifying information, and on and on.
Expand to include start-ups and the breadth and scope of products being developed grows dramatically.
All the time, across all of these situations, you face engineers, product managers, sales people, and many others, who over-promise on product offerings during initial stage sales piloting. It happens all. the. time. And one of the most serious drivers of this huge and risky oversight is a lack of investment in building parts of the product in advance of attempting to sell it, in order to acquire knowledge that you did not already have regarding the cost and blockers of the engineering implementation.
That you dismiss this as implausible by saying “confidence that you are capable of building what you are selling is given” is nothing other than an indication you do not know what you’re talking about in this topic. I feel frustrated to receive such a rude comment that is self-evidently more focused on trying to undercut me, even mentioning wildly non sequitur things about concise writing as if it applied to the original article, than focused on the actual discussion of the thread.
It just doesn't invalidate the point the article is making.
Your point - which I'll paraphrase as don't sell something you can't build - is valid and important.
The article's point - which may be paraphrased as don't build something you can't sell - is also valid and important.
Neither is more important than the other; like basically everything in business there is a tradeoff, and the ones who succeed will be the ones who get the tradeoff right.
But the author makes their point because they see too many people over-optimising on the "build first" approach and failing, when they might have avoided failure if they'd done a bit more "sell first" - or, as the article actually says, "talk to potential customers to properly understand what they want first".
You're getting frustrated (indeed, coming across as enraged) and resorting to strawman and absurdist arguments because you're incorrectly seeing the article as making an absolutist point, and then responding to it with your own opposing absolutist point. If you just approach the topic with appropriate nuance you'll save yourself the need to be frustrated.
Edit: changing implied quotes to be clear they're paraphrased.
Sure at a big company. But this advice is targeted to engineers who want to start their own company. Its unlikely they can even afford any of the layers of cruft you are talking about.
If this was advice for starting some new initiative at BigCorp I might agree with you.
The need to build before selling is more critical for start-ups or single person gigs or consulting, because in those situations you don’t have existing stable revenue streams to use to absorb financial or reputational losses that come from underestimating implementation time or cost and failing to deliver sales promises.
If it matters to build before selling in a mature company, it matters even more in a start-up / solo business / consulting feasibility discussion / etc.
No, not currently; however, we offer hosted deployments of PipelineDB as well as a SaaS product called Stride (stride.io), which is based on PipelineDB.
Just out of curiosity, do you have a specific use case that necessitates stream-stream JOINs, or were you just exploring the docs and wondering about this?
My use case is pretty much parallel time series alignment with several layers of aggregation. I guess I perceive stream-stream joins as an easy way for me to wrap my head around how to structure my compute graph, but it seems doable with the method mentioned by @grammr. I'd hope for an interface roughly like "CREATE join_stream from (SELECT slow_str.key AS key, sum(slow_str.val, fast_str.val) AS val FROM slow_str, fast_str INNER JOIN ON slow_str.key = fast_str.key)". I do realize there are some tough design decisions for a system like this, but I'd also like to drop my wacky zmq infrastructure ;)
Fundamentally different approaches. Citus focuses on horizontal scaling for PostgreSQL and PipelineDB focuses on continuous aggregation for large volumes of streaming time-series data.
