> And to keep making money in these markets — already a ridiculous $27 in ARPU for the last three months of 2017 — they need us to give more time and attention to them.
And that there is the Achilles' heel of both Google and Facebook: disrupting the attention market.
I've been having a debate with someone on this subject, and it prompted me to run a consumer survey asking people: "Thinking about free services (e.g., print, radio, TV, websites), do you like it when they sell your attention to advertisers?" Yes, No, Undecided.
Of 511 responses, only 6% liked having their attention sold. 68% dislike it, and 26% were on the fence.
Personally, I think there is a huge opportunity to re-invent the attention market. Until then, companies like Google and Facebook will keep stealing our attention and selling it to the highest bidder.
> How was Google making a living before advertising?
It wasn't. Every search engine at the time had struggled to make money. It wasn't until Google "borrowed" pay-per-click auction bidding from Overture that advertising became their focus.
I suspect they'd planned to roll out enterprise products. (You know - "the box" - like they did in Silicon Valley). That business started later (circa 2002):
BUT the ideas are easy. The problem is market testing each idea to see what works.
ProductHunt is going in the right direction - but unfortunately the products are already built with little or no market testing so I predict a high failure rate.
KickStarter is a nice way to see if there is some market demand, but also a high failure rate (55%) by people who lack the experience to execute.
It sounds like Andy Hunt has finally discovered ISO 9000. Plan. Implement. Measure. Review. Improve.
The pattern I keep seeing is the IT community's need to re-invent the wheel and give it names like 'agile', 'scrum', etc. Why can't people call a wheel a wheel?
I usually start by writing comments first in plain English based on a variation of psuedocode. That way I'm focused on process first without distraction. Comments are the plan. Clearly articulated steps like any good cookbook. Easy to translate into any language.
// 1. Write plain English psuedocode.
// 2. Translate into scary looking code blocks.
// 3. If maintaining, remember to update comments first (goto Step 1, then Step 2).
The irony is another developer once claimed that my code was generated by a machine. Apparently it was too methodical to be human. Like that was some excuse for him to write crappy code. Urgh! To be great at anything, you need to have excellent communication skills!
I rather view the internet as a party where everyone is invited. The social networks are the loud attention seekers yelling "look at how cool we are". People are wow'd and sucked in. The problem is, it's a keg party and the only way they've been able to monetize is to sell ads at their party. Once the ads go up, the venue is no longer cool and the party moves to a new venue.
Of course, there are other types of parties and my prediction is that quality is going to trump quantity in future networks. Who wants a keg party that sells advertising when the quality of the people I meet at a cocktail party could lead to new opportunities without advertising?
The next wave will build on social and actually generate real value. Therefore, it'll have a new name and it won't be Social 2.0 It'll be something entirely new that addresses that value.
I ALWAYS quote fixed price projects regardless of scope. Some software engineers would say that's highly risky. For me, it tends to be highly profitable because my estimates are usually accurate. If anything, I've learnt to over estimate and impress clients by delivering on promises.
I am amazed by the number of people who try to portray computer science as a pseudo science like voodoo, where estimates are impossible because the problems are unknown. Just because information is abstract doesn't make it any more difficult to estimate than something physical. Computer science IS a science and software engineering IS engineering. Good engineering involves breaking problems down into small manageable pieces that are easily understood then planning how to implement them. This practice is called design. On more complex projects it's architecture - a sexier form of design.
Let's get back to basics. Who has heard of "the software development life cycle"? Everyone, I hope. It's modeled off something from the early 19th century called the product development life cycle. It needs to be mentioned because IT people like to think they're special and mysteriously invented SDLC. Feasibility, analysis, design, development, testing, deployment, etc. Agile methods are simply a minimal version of this repeated fast and frequently. Release the minimum viable product then iterate. Unfortunately, so called "hacking culture" has led people to jump straight to development without considering analysis or design. Real hackers design their attacks first. Successful hacks are well thought out and executed in small brilliant steps.
The analogies of sudoku in defining a problem and construction in defining a project are perfect, so I'll borrow those.
If someone presents me with a 1000 sudoku puzzles of varying difficulty, the first step in estimating is to DESIGN a solution. Allocate time to categorize each puzzle by complexity. Then estimate times based on complexity based on past experience. Anyone who says they can't do this because they have no experience with the problem should be immediately fired. You've obviously misrepresented your experience and/or skills as an engineer of sudoku problem solving.
If a problem is truly unique and novel (and very few are nowadays), then simply factor in time during the analysis & design to perform a few experiments that will more accurately help with estimation. Or training. OR HIRE SOMEONE WHO HAS DONE IT BEFORE to help with design and estimations. Then find the most effective resource to implement (solve) each puzzle.
As for construction, any idiot can slap a few lines down on a piece of paper and call it a design for a house or a building. That's the way some people are building software. Real architects and engineers exist because construction can be broken down into hundreds of thousands of pieces and estimated accurately. They know exactly how many bolts it will take and what types of contingencies to allow for. Software, although abstract, is no different. The software industry has been around for 40+ years and it's modeled off past industries like construction and manufacturing. It can be accurately designed and estimated.
Once a clear design exists, estimation is easy.
My preferred estimation method is function point analysis. It's simple. Break each problem down into the smallest manageable piece. Any piece that takes longer than a couple of hours is too large and should be broken down further. That's an excellent rule of thumb. Anything longer than a couple of hours also suggests the design was poor.
Of course, in some organizations this fails due to a lack of clear process. An analyst will be tasked at collecting business requirements to write a specification. That is often full of nonsense written by someone with no design experience. That specification is given directly to a developer for estimation and development. Where was the design? The nonsense works it's way into the product. It becomes an estimation nightmare. Projects and budgets run over or worse, fail.
How do I know this works?
When I break a job down for a client into small manageable pieces I know the entire scope and can estimate accurately.
Clients love it because they can see every single piece of the puzzle in the design. The quantity and times for each piece look reasonable when broken down. The clients begin to appreciate the scope but ultimately don't care how it's built or what technology is used. They just want to know how much and when? If there is a deadline? Either add more resources or cut functionality. Let them make that choice. It's not my concern.
The cream, and why this industry is so much better than construction and manufacturing, is to look at all the pieces and see the re-usable patterns. Design optimization. Copy, paste and re-use as much as possible. Clients don't care about re-usability. I charge top of market rate and still manage to be cheaper than competitors because my estimates were realistic (as opposed to their crystal ball methodologies). Re-usability and working smarter then gives me 4-5x that hourly rate. Shh! Don't tell the clients :)
If you can't estimate software accurately, you're clearly in the wrong business!
And that there is the Achilles' heel of both Google and Facebook: disrupting the attention market.
I've been having a debate with someone on this subject, and it prompted me to run a consumer survey asking people: "Thinking about free services (e.g., print, radio, TV, websites), do you like it when they sell your attention to advertisers?" Yes, No, Undecided.
Of 511 responses, only 6% liked having their attention sold. 68% dislike it, and 26% were on the fence.
Personally, I think there is a huge opportunity to re-invent the attention market. Until then, companies like Google and Facebook will keep stealing our attention and selling it to the highest bidder.