Skip to main content


Beiträge die mit mistakes getaggt sind


EU Copyright: Block Everything, Never Make Mistakes, but Don't Use Upload Filter

As we've been discussing the "Trilogue" negotiations between the EU Commission, EU Council and EU Parliament over the EU's Copyright Directive have continued, and a summary has been released on the…
Article word count: 2671

HN Discussion:
Posted by em3rgent0rdr (karma: 3682)
Post stats: Points: 141 - Comments: 88 - 2018-12-11T00:30:21Z

\#HackerNews #block #but #copyright #dont #everything #filter #make #mistakes #never #upload #use
Article content:


As weʼve been discussing the "Trilogue" negotiations between the EU Commission, EU Council and EU Parliament over the EUʼs Copyright Directive have continued, and a [1]summary has been released on the latest plans for [2]Article 13, which is the provision that will make upload filters mandatory, while (and this is the fun part) insisting that it doesnʼt make upload filters mandatory. Then, to make things even more fun, another document on the actual text suggests the way to deal with this is to [3]create a better euphemism for filters.

When we last checked in on this, we noted that the legacy film and television industry associations were freaking out that Article 13 might [4]include some safe harbors for internet platforms, and were asking the negotiators to either drop those protections for platforms, or to leave them out of Article 13 altogether and only have it apply to music.

The latest brief description of the recommendations for Article 13 appear to be an attempt by bureaucrats who have no understanding of the nuances of this issue to appease both the legacy copyright industries and the tech companies. Notably absent: any concern for the public or independent creators. Weʼll dig in in a moment, but frankly, given the state of Article 13 demonstrated in this two-page document, it is horrific that these discussions are considered almost concluded. It is obvious that the vast majority of people working on this have no idea what theyʼre talking about, and are pushing incredibly vague rules without any understanding of their impact. And rather than taking in the criticism and warning from knowledgeable experts, theyʼre just adding in duct-taped "but this wonʼt do x" for every complaint where people warn what the actual impact of the rules will be for the internet.

Thatʼs why, throughout this document, they keep insisting that there will be no mandate for filters. But, thereʼs no way you can actually avoid liability without filters. Indeed, in order to appease the film and TV folks, the proposal now includes a notice-and-staydown provision. Weʼve spent years explaining why a notice-and-staydown provision is not only unworkable, but would lead to tremendous amounts of non-infringing content being removed. Copyright is extremely context specific. The exact same content may be infringing in one instance, but protected in another. Yet a notice-and-staydown does not allow the protected versions. It requires they be blocked. That is outright censorship.

On to the document. It starts with seven "guidelines."
The Commission was requested to follow these guidelines indicated by the Rapporteur: 

   \* Platforms should follow high standards of duty of care; 
   \* Cooperation should not be unidirectional; 
   \* Non infringing content should remain on the platform online; 
   \* Automatic blocking, albeit non forbidden, should be avoided as much as possible 
   \* Existing measures should not be excluded 
   \* Platforms should not always be released from liability by merely applying content identification measures 
   \* Rightholders should not be in a worse position than they are currently. In this context the audiovisual sector was singled out. On this basis, the following ideas, which are based on a logical grouping of the above guidelines, are outlined for the consideration of the co-legislators:

This can be summed up as... all infringing content must disappear, but you donʼt have to use filters and you must make sure that non-infringing content remains online. This is the "nerd harder" approach to regulating. It is magic wand regulating: make the bad stuff go away, and magically donʼt have any collateral damage.

This is not sound policy making. This is technically illiterate bureaucrats trying to cover their asses. Because the liability requirements in the document will certainly lead to massive overblocking and widespread unintended consequences, these spineless technocrats are trying to avoid that by just tacking on "but let those consequences happen." They donʼt explain how this is possible. They just are going to put these rules out into the world, and tell the tech industry to wave a magic wand and make one type of content disappear without impacting other content (even if theyʼre impossible to distinguish, and if the penalties for getting it wrong are dire).

From there, the document provides "details" never apparently recognizing just how contradictory the plans are:
High standard of duty of care and bilateral cooperation (1 + 2) Online content sharing service providers, as defined in the directive, are considered to communicate to the public and as such need to obtain licences from the relevant rightholders. Where no licences are granted, online content sharing service providers and rightholders should cooperate in good faith to prevent the availability of protected content online. 

 Cooperation should take place according to appropriate standards of professional diligence, which ought to take into account the size of the service, the number and type of works or other subject matter uploaded by users, the potential economic harm caused to rightholders, the availability of suitable and effective technologies and their cost for service providers. In practice, this means that the standards of cooperation should be particularly high for high value content. Cooperation should not lead to a general monitoring obligation as defined under the e-Commerce Directive.

Magic wand thinking: Either your entire platform needs to be licensed (i.e., no user-generated content) or you need to "prevent the availability" of any copyright-covered content with "good faith." But how? Well, the bureaucrats insist that this shouldnʼt require "general monitoring" (i.e., an upload filter). But... um... how do you prevent availability of copyright covered content if youʼre not monitoring? This is an impossible situation and either the bureaucrats know this and are just ignoring that theyʼre demanding the impossible, or they donʼt understand this and shouldnʼt be allowed within 10 miles of any regulation over the internet.
Rightholders should provide content sharing service providers with specific information (e.g. metadata) allowing identification of their content. 

 The cooperation could include content identification measures (e.g. for high value content) but should not prevent other forms of cooperation if agreed by the parties (e.g. ex post content moderation for low value content, see also letter B). 

 When unauthorised content becomes available on their websites, content sharing service providers would in general not be liable if they have cooperated in good faith according to the relevant standards of professional diligence. However, within an adequate framework to ensure legal certainty, when despite such cooperation the availability of content online has caused significant economic harm to rightholders the Directive could consider the provider liable in any event, but at a reduced level taking into account the good faith of the provider. Alternatively, the Directive could allow rightholders to claim restitution of the benefits appropriated by the providers (e.g. using unjust enrichment claims under national law) (see point C below).

So, again, we see the general incomprehensibility of what is being pushed here. The first paragraph is an attempt to appease the platforms, basically saying "if copyright holders are going to demand takedowns, they should at least be required to supply the details of what content they actually hold a copyright over." Thatʼs reasonable given a plan to demand mandatory filters, because the only thing such metadata is actually useful for is... a filter.

The second paragraph is basically saying "okay, yes, we mean filters for loosely defined ʼhigh valueʼ content, but maybe loosely defined ʼlow value contentʼ doesnʼt require filters." Again, this appears to be an attempt to split the baby. Who the hell is going to self-describe their own content as "low value content?" The whole concept of "high value" and "low value" is elitist claptrap from the legacy content industries who basically believe that anything that comes from the legacy recording, TV and film studios is "high value" and all that independent, amateur, and user-generated content is "low value." The paragraph here is supposed to be an attempt to say "well, okay, if your platform is just publishing garbage memes and stuff maybe it doesnʼt need a filter, but if you happen to include any of Hollywoodʼs precious brilliance, you must put in place a filter."

The third paragraph is, yet again, an attempt to give special extra rights to the legacy recording, TV, and film companies. It basically says that if platforms try to "cooperate in good faith" (i.e., censor at the drop of a hat) then maybe they would be considered not liable... but only if itʼs that riff-raff low value content that slips through the filters (though weʼre not demanding filters!). If any content slips through the filters that "caused significant economic harm" (i.e., comes from the big copyright industries), well then, it doesnʼt fucking matter how much you tried to stop it, youʼre still liable.

In other words, if any internet platform makes a single mistake with Hollywoodʼs content, no matter how hard they tried to stop it, too bad, youʼre liable.

And this is where thereʼs such a massive disconnect between the framers (and supporters) of Article 13 and reality. When youʼre told that any mistake will lead to liability, you are put in a position of trying to prevent any mistakes. And the only ways to do that are to (1) stop accepting any user-uploaded content or (2) filter the hell out of all of it, and take down anything that even might possibly be considered infringing, meaning tons of perfectly legitimate content will get shut down.

No matter how many times these technocrats say "donʼt take down non-infringing works", itʼs totally meaningless if the only way to avoid liability is to take down tons of non-infringing works. Which brings us to the next part:
Non infringing content should remain online and automatic blocking to be avoided as much as possible (3+4) 

 Content that does not infringe copyright, for example because it is covered by exceptions, should stay on the services’ websites. In addition, the co-legislators could provide that minor uses of content by amateur uploaders should not be automatically blocked (in the context of the cooperation and professional diligence referred to under A) nor trigger the liability of the uploader. This should be without prejudice to the remedies under point C and the rules on liability of the providers and cooperation under A. 

 The need to allow legitimate content to remain available, should be strengthened through a robust redress mechanism which should ensure that users can contest measures taken against their legitimate uploads. The Commission already provided possible suggestions to the co-legislators which are currently under discussions in the trilogue process.

Again, this is setting up a laughable impossibility. First they say youʼre liable if you let anything through, and then they say "but donʼt accidentally take down stuff you shouldnʼt." How the hell do you do that? The rules donʼt say. Hollywood and Article 13ʼs supporters donʼt care. Itʼs great if they add a "redress mechanism" for bogus takedowns, but that only will apply to content that first gets up and then is taken down. It says nothing for content that is blocked from being uploaded in the first place due to overaggressive filters, which are only overaggressive due to the earlier parts of Article 13 that say youʼre liable if you let anything "high value" through.

This is the ultimate in cowardice from the EU regulators. Rather than address the actual problems that their own regulations will create, these regulators have decided to just append a bit to their regulation that says "and donʼt let this create the problems it will obviously create." Thatʼs fucking useless.
Rightholders should keep benefiting from existing measures; and platforms not released from liability by merely applying content identification technologies. Rightholders, notably audiovisual sector, not worse off (5+6+7) 

 Rightholders should in any event retain the ability to request removal of infringing content from the websites of the content sharing services. Building on and complementing the current ecommerce rules, rightholders should be allowed to request that unauthorised content is expeditiously removed and that best efforts are made to ensure that it stays down. As indicated in A, the co-legislators may provide for an additional safeguard for rightholders when despite the good faith cooperation the availability of content online causes significant economic harm to them.

Thereʼs something really big hidden in here. A "notice and stay down" requirement. That was not what was being pushed before. [5]Notice and staydown creates all sorts of problems, in that by its very nature it obliterates the points in the previous paragraph. If you have a notice and staydown regime, you cannot allow content that is "covered by exceptions" because youʼve already designated all such content must stay down. And unless these bureaucrats in Brussels have magically invented a filter that can understand context and correctly judge whether or not something is covered by an exception (something that normally takes a years-long adversarial judicial process) it is difficult to see how this is possible.

Then we get to [6]the other document, leaked earlier today by Politico, that attempts to wordsmith the actual language of Article 13. Itʼs basically the same stuff we discussed above, but with an attempt to put it into actual legalese. Two things stand out in the document. First, they try to rebrand mandatory upload filters, by now discussing "suitable and effective technologies" to "ensure the non-availability on the websites of the service providers of unauthorised works or other subject matter..." How is that not a filter?

This document also includes some language "as an option" that would require "best effort to prevent their future availability." Thatʼs putting the notice-and-staydown into the law. I will note that there is no real language being discussed that explains how to prevent the blocking of non-infringing works. Just more hand waving and magical thinking about how it shouldnʼt block non-infringing works... even though it absolutely will.

This leaves me with two key takeaways:

1. The bureaucrats putting this together are doing the worst kind of regulating. They appear to be utterly ignorant of what it is that they are regulating, how it works, and the inevitable impact of their new rules. And, rather than trying to take the time to actually understand the concerns, they are simply writing "but donʼt do that" into the law every time someone explains the impact. But you canʼt regulate internet platforms not to overblock when everything else in your law requires them to overblock or face crippling liability. This is like a law that says "you must immediately dump out the bathwater without looking to see whatʼs in the bath... but donʼt throw out the baby with the bathwater." How do you do that? The law doesnʼt say because the regulators donʼt have the slightest clue. And they donʼt have the slightest clue because itʼs impossible. And, they donʼt seem to care about that because once they pass the law they can celebrate and the mess they create is left for the internet platforms (and the public) to deal with.
2. Given the massive changes and broad and unclear mandates being tossed around, Article 13 is nowhere near a condition which should be put into a binding regulation. Whatʼs being debated now is so unclear, so vague and such a mess, that it would be practically criminal to put such nonsense into law. They are rushing to get this done (perhaps before the next EU Parliamentary elections next spring), and the fact that theyʼre about to make massive changes to a fundamental part of society (the internet) without clearly comprehending what theyʼre doing is incredibly frightening. This is like a bad first draft of a bad proposal. This is not just "this is a bad bill that went through a comprehensive process and I disagree with it." This is an utter mess. It keeps shifting, it has vague and contradictory definitions, it tells companies to wave magic wands, and tells companies not to let the very thing the law compels actually happen. This is not regulating. This is why the public hates regulators.

Iʼm still hopeful that common sense eventually shows up in the EU, but at this point the only way for common sense to survive is to simply dump Article 13 entirely.


Visible links

HackerNewsBot debug: Calculated post rank: 123 - Loop: 169 - Rank min: 100 - Author rank: 21

- #Chinese #facial #recognition #system #mistakes a #face on a #bus for a #jaywalker
China’s facial recognition systems are used to catch all types of criminals, from thieves to jaywalkers, in real time. This week, one facial recognition camera publicly shamed a famous business woman for jaywalking after its systems caught her face crossing an intersection. The problem? She was never physically there.


1.e4 e5 2.Nf3 d6 3.Bc4 h6 4.h3 Nf6 5.Nc3 c6 6.d3 Be7 7.a3 O-O 8.O-O Nbd7 9.Nh2 Qc7 10.f4 b5 11.Ba2 Bb7 12.f5 d5 13.Ng4 Bc5 14.Kh1 d4 15.Ne2 Nh5 16.Ng1 Ng3 17.Kh2 Nxf1 18.Qxf1 Be7 19.Bxh6 gxh6 20.Nxh6 Kh7 21.Qc1 Bf6 22.Bxf7 Bg7 23.Bg6 Kh8 24.Ng4 Nf6 25.Qg5 Nxg4 26.hxg4 Bf6 27.Qh6 Kg8 28.g5 Qg7 29.Qh4 Qh8 30.Qh3 Qxh3 31.Nxh3 Bd8 32.g4 Bc7 33.Kg3 Kg7 34.Kh4 Rh8 35.Bh5 Bc8 36.f6 Kf8 37.g6 Bd8 38.g7 Kg8 39.gxh8Q Kxh8 40.Ng5 Bxf6 41.Re1 Bd7 42.Rf1 Kg7 43.Rf5 Bxf5 44.exf5 a5 45.Bg6 Be7 46.Kh5 b4 47.Ne6 Kg8 48.axb4 axb4 49.g5 Ra2 50.f6 Bd6 51.Kh6 Rxb2 52.f7 Kh8 53.Bf5 Rxc2 54.g6 Rh2 55.Kg5 Rg2 56.Kf6 Rxg6 57.Kxg6 b3 58.Kf6 b2 59.Ng5 b1Q 60.Ke6 Qb4 61.f8Q Bxf8 62.Nf7 Kg7 63.Nxe5 Qe7#  {Black Wins}

I’ve been a frustrated #chess player for decades, mainly because I hadn’t made any effort to study the game. And since I mostly play #blitz or #bullet #online (usually 5 minutes), I’m particularly vulnerable in the #middlegame and #endgame.

I’m trying to change course, but that requires breaking old #habits. Here is where IM Jeremy #Silman helps by outlining his analyses of #imbalances that even a flawed #novice like myself can understand.

Today’s win wouldn’t have been possible otherwise. After a sloppy middle game full of #mistakes and #blunders, I was left with my king cornered by white’s pawns, bishop, knight, and king. The rook sacrifice with less than 10 seconds to play
56 ... Rxg6+

allowed pawn on b4 to promote easily, leading to a reversal of fortune with seconds to spare. #Persevere.


Sales mistakes that software engineers make

Everybody is selling something. For software engineers this can translate to selling products directly to customers on the front lines or selling new product feature ideas internally within an…
Article word count: 2589

HN Discussion:
Posted by Fergi (karma: 409)
Post stats: Points: 135 - Comments: 29 - 2018-11-01T07:13:09Z

\#HackerNews #engineers #make #mistakes #sales #software #that
Article content:

Everybody is selling something.

For software engineers this can translate to selling products directly to customers on the front lines or selling new product feature ideas internally within an organization. In either case, sales in some form cannot be avoided. As such, software engineers can benefit greatly from observing and avoiding the more impactful and common mistakes other developers have made in the past, and learning what they should have done instead.

When we went through Y-Combinator during the winter of 2014 and were just starting [1]PipelineDB, one of the things that surprised me most about the other founders in our YC batch, who were mostly technical, was their bewilderment at the prospect of selling. Here were some of the most brilliant minds I’d ever met, building things ranging from self driving cars to aerial imagery analytics platforms for agriculture, and the aspect of their startups that seemed to cause them the most anxiety was sales.

And then it occurred to me that it wasn’t because sales is prohibitively complex or difficult that these genius technical minds were baffled by it. It was simply a situation where they didn’t know what they didn’t know. Ambiguity is inherently stressful.

This post aims to help software engineers bridge the gap between conceptualizing valuable software products and winning deals by observing three significant mistakes developers commonly make when approaching sales. We’ll frame these mistakes in a positive light, more as opportunities for progress than as liabilities, focusing on solutions in each instance.

Each of these mistakes is fairly unintuitive, so it’s not surprising that any salesperson, including software engineers, would make any of them.

Sales Mistake #1 - Building Before you Start Selling

The biggest mistake I see developers make is assuming that they are building something that people both want and will pay a meaningful amount of money for. Many engineering teams spend a great deal of time and money building products that people either don’t actually want, or want but aren’t willing to pay enough money for, such that the company building the product can establish a feasible business model. Both of these issues can be resolved simply by talking to potential customers before the product is ever built and asking strategic questions, a step which many developers fail to take.

Ironically, the amount of work required to talk to potential customers and prove demand for a potential product is almost exactly the same as the amount of work required to sell an existing product. So, the sales work we’re talking about here has to be done at some point, regardless. One benefit of doing this sales work in advance of building the product is that if you’re right about the extent to which people want what you’re building, you’ll be lining up customers for sales as soon as the product is ready and learning more about what features people need and will pay for in the process. If you’re wrong, you’ll save time and money by not building something people don’t want.

Plus, if you’re a startup looking to raise money and haven’t built the product yet, or are working at a company and looking to win internal support for the development of a new product or feature, there is no better ammunition for pitching investors or internal champions than hard, documented customer demand. This documented customer demand will carry weight only if it demonstrates a propensity, or better yet, a contractual obligation, to pay a meaningful amount of money for whatever you’re building.

Strategically engaging with and selling to potential customers before you build your product is a far superior strategy than building a product and then taking it to customers and trying to sell it, so do yourself a gigantic favor and check your assumptions before you start building and test your hypothesis about both people’s interest and willingness to pay for what you want to build, before you build it. No amount of salesmanship will enable you to make up for building the wrong product.

So how do we accomplish this? Below is a quick overview of the steps required to find and engage potential customers, along with a couple of helpful tools and strategies to help you get the job done.

1. Clearly articulate your hypothesis about what you’re building. What is the product? Who wants this? Why do they want it? What will they pay for it? How do you know they’ll pay that much? How many potential customers exist? Be as concise as possible with your answers to these questions. The simpler the response, the better. Without a well thought through hypothesis you’ll have nothing to test or measure against.

2. Create a list of companies (or users) that you think fit your hypothesis in a spreadsheet or simple CRM (customer relationship management) tool like [2]Streak, a lightweight CRM offered as a Gmail plugin. This CRM will be your data management platform for all customer interaction and can be used to organize your target list of companies, monitor your sales progress, document customer conversations and feedback, and ultimately measure your sales results.
The most common way to organize a CRM is by grouping companies you’re targeting by the stage of the conversation that each company is in with you. I’d suggest using (“lead”, “reached out”, “active contact”, “demo/free trial”, “closed/won”, “closed/lost”, and “future interest”) or some close variant, as your stage names. It is imperative to have and use a well organized CRM of some sort, even if it’s just a simple spreadsheet.

3. Find relevant contacts at each company on your target list and document their names, titles, and contact information in your CRM. You can use [3]LinkedInʼs search feature to find employees who work at each company you’re targeting, along with their titles and oftentimes descriptions of their roles. You can also browse the “about us” section of the websites of the companies you’re targeting and conduct basic Google searches to find the names and titles of employees you want to talk to. Try to identify a handful of relevant contacts at each company. Having multiple points of entry for each company increases your chances of successfully setting up a meeting with that company, which should be your goal.
You can use tools like Linkedin’s [4]Sales Navigator Gmail plugin (was called Rapportive) to help you find contact info for the folks on your list. If you don’t connect with the right contact initially, ask the person you do connect with who they would suggest you talk to and if they’d be willing to make a quick email introduction to that person. I’m always surprised at people’s willingness to be helpful when I’m direct, sincere, and respectful of their time. And work your own personal network. The best introductions are warm intros from people you already know, so leverage your network as much as possible.

4. Reach out to each of the contacts you found. In my experience, the optimal strategy is to write concise and highly personalized outreach emails to each contact explaining who you are, why you’re reaching out, and why they should care. Conclude by asking if they would be open to a brief introductory conversation with you to learn more about your product and how it might help them. The goal is to get them on the phone to discuss your product and test your hypothesis from step one.

Effective selling requires a thoughtful strategy, rigorous effort, and tenacity. There is obviously more to sales than can be articulated in this post alone, but this high-level framework for finding and engaging potential customers is something that software engineers can use to get sales conversations started and generate the type of crucial customer feedback discussed above, before building. Be scrappy and creative in how you find and engage contacts, but make sure that you don’t stop until you have a significant amount of clear feedback that either proves or disproves your hypothesis. And don’t be afraid to iterate on your hypothesis and pivot your product strategy or business model. Iteration is a normal and expected part of a successful product development process, so let go of any attachment you have to what you think people want, and build what they tell you they actually want and will pay for instead.

Sales Mistake #2 - Talking Instead of Listening

The second biggest mistake I see developers make in the sales process is entering into sales conversations with potential customers and proceeding to immediately talk about product features and perceived benefits for the customer, without taking advantage of the opportunity to ask strategic, open-ended questions, and then listen intently. The responses that customers give to thoughtful, open-ended questions inform how customers think about their problems, needs, budgets, timeline, decision making process, fears, alternative options to your product, and the extent to which they perceive that your product solves their problem.

When it comes to sales, it does not matter what you think about your product. It only matters what customers think about your product. In order to win customers you must set aside your own thinking and get into the mind of your customer. The best way to do this is by asking good questions, and then listening carefully and taking notes. Open-ended questions like:
\* How do you think about this problem? 
 \* To what extent is this a priority? 
 \* Why are you interested in this topic? 
 \* How will the decision to do this or not be made? 
 \* What are your most important considerations with this type of project? 
 \* How exactly did this need surface in the first place? 
 \* What would solving this problem do for your team, and the business as a whole?

are particularly effective sales questions because they offer the sales prospect an opportunity to respond with a large volume of unbiased feedback to each of your questions. The goal is to get sales prospects talking about their thought process so that you can understand their perspective, needs, and motives. Without this information you are essentially flying blind in the sales process and likely inundating sales prospects with information that may or may not be relevant. With this information you can deliver a concise, tactical proposal about how your product would add value for them, or determine that your solution actually isn’t a good fit for them and save both you and the prospect time by disqualifying them and moving on to another sales conversation that is likely a better fit.

Many engineers Iʼve talked to report experiencing social anxiety and a sense of discomfort during sales conversations. This is especially true when itʼs time to ask sales prospects some of the harder questions surrounding their willingness to pay for your product, budgets, next steps, and getting all of the decision makers on their end involved and taking action. The natural human response to this type of discomfort is to react somehow, oftentimes by talking unnecessarily, which is a tactical mistake. The optimal approach to sales is to ask the kind of strategic, open-ended questions mentioned above, then wait. Listen. Let the silence linger longer than youʼre comfortable with, so that the sales prospect can consider your question, experience their own emotions, and then respond. Get comfortable being uncomfortable.

Asking good questions is the key to sales. This key can be used to unlock the door to the customer’s thought process. Once the door is open, valuable information can be passed from the customer to you, enabling you to deliver value to the customer. And by delivering value, you will earn revenue.

Sales Mistake #3 - Mistaking Interest for Demand

Software engineers, especially those who are emotionally attached to the value propositions they assume their products’ deliver, have a tendency to mistake interest for demand. If you’re building a product that delivers any incremental value, you’ll likely be able to win the interest of potential users, but that does not mean that you have created enough incremental value for customers to make them willing to pay you a meaningful amount of money for your product. The delta between enthusiasm and willingness to pay is the difference between interest and demand.

What typically happens is that customer prospects will express some level of enthusiasm about a product during a sales call, or even go as far to articulate that they want and would use the product in question. This response from the customer is then interpreted as proof that customers want to buy the product. Software engineers in this situation have a tendency to assume that their sales work is now done and that the only remaining step is to deliver the product and collect their cash. This is incorrect.

More investigation must be conducted to determine whether or not the customer is willing to pay for the product, and if so, how much they are willing to pay. The acronym “BANT” (budget, authority, need, timeline), which was developed by IBM salespeople for qualifying sales leads, is a useful checklist for determining whether not a sales prospect has demonstrated demand for your product. If you can determine that a customer truly:

1. needs your product
2. has enough budget to purchase your product at a price that works for you
3. that you are in contact with a person who has the authority to make the purchase
4. that the transaction will likely be completed in a timeline that is acceptable to you

then you have successfully bridged the gap between interest and demand. Once you have determined that a sales lead has met these criteria, ask them if they’d be willing to sign an agreement to purchase your product at a specific price if it meets a certain set of requirements. The ideal situation for you is to have as many signed, legally binding customer contracts as possible, as early on in the product development process as as possible. You may not be able to get these, but you should try. Even getting customers to sign non-binding “letters of intent” to purchase your product, ideally at a set price, is valuable and can be used to build your case to any relevant parties. You must push customers to agree to as much as possible. Without doing this, you will not have a good sense for the extent to which demand for your product exists.

Don’t fall into the trap of mistaking people’s enthusiasm and language around how much they want and will use your product for real demand that satisfies your business hypothesis. It’s possible to waste an infinite amount of time chasing unqualified leads, or worse, mistaking interest for demand and building the wrong product entirely.


The majority of software products and companies that fail do so because they neglect to perform the kind of thorough customer development work described above. The process of strategically engaging customers and transforming their feedback into valuable software products is the best way to ensure that you build something that delivers enough value to these customers for them to be willing to pay you a meaningful amount of money in return.

This iterative process of talking to customers and building what they need and will pay for is not only an exercise to be conducted before building products, but should also serve as a continuous feedback loop between customers and developers. Don’t deny yourself the opportunity to harvest mission-critical information needed to build game changing software products that support successful business models, simply by neglecting to engage the very people you’re aiming to help.

Talk to your customers, build what they want and will pay for, and iterate relentlessly.


Visible links

HackerNewsBot debug: Calculated post rank: 99 - Loop: 72 - Rank min: 80 - Author rank: 45


Incomplete List of Mistakes in the Design of CSS

That should be corrected if anyone invents a time machine. :P white-space: nowrap should be white-space: no-wrap and line wrapping behavior should not have been added to white-space vertical-align…
Article word count: 825

HN Discussion:
Posted by zdw (karma: 30758)
Post stats: Points: 98 - Comments: 68 - 2018-10-25T00:49:01Z

\#HackerNews #css #design #incomplete #list #mistakes #the
Article content:

That should be corrected if anyone invents a time machine. :P
\* white-space: nowrap should be white-space: no-wrap 

      \* and line wrapping behavior should not have been added to white-space 

 \* vertical-align should not apply to table cells. Instead the CSS3 alignment properties should exist in Level 1. 

 \* vertical-align: middle should be text-middle or x-middle because itʼs not really in the middle, and such a name would better describes what it does. 

 \* Percentage heights should be calculated against fill-available rather than being undefined in auto situations. 

 \* Table layout should be sane. 

 \* Box-sizing should be border-box by default. 

 \* background-size with one value should duplicate its value, not default the second one to auto. Ditto translate(). 

 * background-position and border-spacing (all 2-axis properties) should take *vertical* first, to match with the 4-direction properties like margin. 

 \* The 4-value shorthands like margin should go counter-clockwise (so that the inline-start value is before the block-start value). 

 \* z-index should be called z-order or depth and should Just Work on all elements (like it does on flex items). 

 \* word-wrap/overflow-wrap should not exist. Instead, overflow-wrap should be a keyword on ʼwhite-spaceʼ, like nowrap (no-wrap). 

 \* The top and bottom margins of a box should never have been allowed to collapse together automatically as this is the root of all margin-collapsing evil. 

 \* Partial collapsing of margins instead of weird rules to handle min/max-heights? 

 \* Tables (like other non-blocks, e.g. flex containers) should form pseudo-stacking contexts. 

 \* The currentcolor keyword should have a dash, current-color. 

 \* There should have been a predictable color naming system instead of arbitrary X11 names. 

 \* border-radius should have been corner-radius. 

 \* Absolutely-positioned replaced elements should stretch when opposite offset properties (e.g. left+right) are set, instead of being start-aligned. 

 \* The hyphens property should be called hyphenate. (Itʼs called hyphens because the XSL:FO people objected to hyphenate.) 

 \* rgba() and hsla() should not exist, rgb() and hsl() should have gotten an optional fourth parameter instead (and the alpha value should have used the same format as R, G, and B or S and L). 

 \* descendant combinator should have been » and indirect sibling combinator should have been ++, so thereʼs some logical relationships among the selectorsʼ ascii art 

 * the *-blend-mode properties shouldʼve just been *-blend 

 \* The syntax of unicode ranges should have consistent with the rest of CSS, like u0001-u00c8. 

 \* Unicode ranges should not have had a separate microsyntax with their own tokenization or token handling. The tokenization hacks required either to make selectors (e.g., u+a) handle things that are unicode-range tokens, or make unicode-range handle the other huge range of tokens (numbers and dimensions with and without scientific notation, identifiers, +) are both horrible. 

 \* font-family should have required the font name to be quoted (like all other values that come from “outside” CSS). The rules for handling unquoted font names make parsing font stupid, as it requires a font-size value for disambiguation. 

 \* Flexbox should have been less crazy about flex-basis vs width/height. Perhaps: if width/height is auto, use flex-basis; otherwise, stick with width/height as an inflexible size. (This also makes min/max width/height behavior fall out of the generic definition.) 

 \* :empty should have been :void, and :empty should select items that contain only white space FIXED in the spec, waiting for implementations to check for Web-compat… 

 \* table-layout: fixed; width: auto should result in a fill-available table with fixed-layout columns. 

 \* ʼtext-orientationʼ should have had upright as the initial value (given the latest changes to ʼwriting-modeʼ). 

 \* The @import rule is required to (a) always hit the network unless you specify cache headers, and (b) construct fresh CSSStyleSheet objects for every import, even if theyʼre identical. It should have had more aggressive URL-based deduping and allowed sharing of stylesheet objects. 

 \* Selectors have terrible future-proofing. We should have split on top-level commas, and only ignored unknown/invalid segments, not the entire thing. 

 \* :link should have had the :any-link semantics all along. 

 \* The flex shorthand (and flex-shrink and flex-grow longhands) should accept fr units instead of bare numbers to represent flex fractions. 

 \* The display property should be called display-type. 

 \* The list-style properties should be called marker-style, and list-item renamed to marked-block or something. 

 \* The ʼtext-overflowʼ property should always apply, not be dependent on overflow 

 \* line-height: <percentage> should compute to the equivalent line-height: <number>, so that it effectively inherits as a percentage not a length 

 \* ::placeholder should be ::placeholder-text and :placeholder-shown should be :placeholder 

 \* ʼoverflow: scrollʼ should introduce a stacking context 

 \* size should have been a shorthand for width and height instead of an @page property with a different definition 

 \* We probably should have avoided mixing keywords (span) with idents in the [1]grid properties, possibly by using functional notation (like span(2)). 
 \* comments shouldnʼt have been allowed basically everywhere in CSS (compare to HTML, which basically only allows them where content goes), because it makes them basically unrepresentable in the object model, which in turn makes building editing directly on top of the object model impossible 

 * The alignment properties in Flexbox should have been writing-mode relative, not flex-flow relative, and thus could have reasonably understandable names like align-inline-* and align-block-*.


Visible links

HackerNewsBot debug: Calculated post rank: 88 - Loop: 97 - Rank min: 80 - Author rank: 115

Operation #clay has suffered a setback. I gathered some wood today in preparation for a fire somewhere. Then I took a nap, and while napping, there was a brief rainstorm. It was very uncharacteristic of the weather around here. The finished pieces got wet, and pretty much all of them were ruined. When a piece gets wet before firing, the water settles in unevenly causing extremely uneven expansion and warpage combined with drastic weakening. It's why you want your pieces to dry slowly, if possible. So, about 90% of my work went back in the bucket to slake back down into "clay water" and then slip. Basically, I had to hit the reset button. This whole thing has been a non-stop lesson in learning by failure! I am not a persistent person, so I decided that I would be persistent on this project. I'd just keep plugging away despite setbacks. And somehow, since I made that decision, I don't really care that there have been setbacks. I guess "persistence" is my real goal. #clay #mistakes #persistence #rain #setback