April is terrific, and I agree that the right messaging and positioning can have disproportionately high impacts on revenue (speaking from experience with Netlify, Gravitational, and others), but this click-bait title is a huge disservice to April, other marketers, and founders who may be dissuaded from trying new messaging and positioning.
The actual story is that the person (April) was asked by a manager to interview a bunch of customers. When they brought back the data, the manager (or the team, collectively) acted on it by coming up with new product positioning.
Some years later, after countless product iterations and three acquisitions, the product landed at a tech giant that does $30B/year. The author speculates it was then responsible for $1B in revenue, though doesn't know for sure.
So...
It's fair to say "I was there early and it was neat to solve these problems for a DB that later ended up at SAP." But to imply that your work directly resulted to $1B in revenue--as this title does--is just nonsense. What the F*ck were the editors thinking.
> How I helped reposition a database product that went on to make $1 billion in revenue
It doesn't say "How I single handedly repositioned" or even "How I repositioned". The author literally helped in the process that led to repositioning. By uncovering a key use-case for the product, which then became the key feature and selling point of the updated product.
And regarding the comment about $1B in revenue, is there any good reason not to give her the benefit of the doubt? She literally worked with the team and rubbed shoulders with them every day. A lot of non-public numbers get talked about casually at the water cooler.
There seems to be a trend where people are hyper-obsessed with nitpicking titles and calling out "clickbait". In this case, the article title is a pretty great representation of the article's contents - or at least as great as you can get in one sentence. I personally enjoyed the article, and was hoping to read a discussion about the main points raised in the article, or similar stories others may have. Instead, the top comment is an angry rant nitpicking the article's title.
1. The title does not make huge claims directly, but strongly implies it. That's how I read it when I was skimming the front page of HN. It's like writing an article with the title "I taught Michael Jordan basketball" and then explain how you showed him how to throw a ball for 30 minutes when he was the 5 years old. Or the old maxim that if you are a cashier at McDonald's, you can technically say that you "process high-frequency cash transactions for multi-billion dollar company on rotating supply-demand cycle".
2. I don't like how the common advice for writing resume, which I can only presume reflects what hiring managers want to see in someone's resume, says you must quantify your achievements. You cannot just say I wrote the login system. You must somehow tie it to a business objective and achievement (increases sales by 7%, reduced support calls by 12%, etc). In reality, projects are often team efforts and except for certain niches such as sales and consulting, there is rarely a clear correlation between an individual employee's actions and business's results. I don't like writing pretending there is and writing it, and I don't like reading it.
> I don't like how the common advice for writing resume, which I can only presume reflects what hiring managers want to see in someone's resume, says you must quantify your achievements.
It's not about résumés but about how the skill of measuring/estimating one's own effectiveness/impact/productivity is positively correlated with successful outcomes and rate of progress in life in general.
Recall Mike Acton's principle questions[0] that a goal-orientated individual must answer:
>> - I can articulate precisely what problem I am trying to solve.
>> - I have articulated precisely what problem I am trying to solve.
>> - I have confirmed that someone else can articulate what problem I am trying to solve.
>> - I can articulate why my problem is important to solve.
>> - I can articulate how much my problem is worth solving.
Or more cynically, keep on doing your thing at your core, but do know that people expect to hear stuff like that so consciously sit down and architect some answers to those things. You can reinterpret and rewrite the story later, but you need to have one. Also you don't have to get too attached to it and believe it too much. Think of it as your interface towards society. They cannot all have time to actually latch onto your inner person. You must present to them all the handles you want to be grabbable by.
> Or the old maxim that if you are a cashier at McDonald's, you can technically say that you "process high-frequency cash transactions for multi-billion dollar company on rotating supply-demand cycle".
Having read about 100 CVs in the past month, this made me chuckle. Yes, people actually word their CVs like this.
I don’t know about pretending a correlation, but a common challenge for engineering and product ICs who are trying to become more senior or have a bigger impact is understanding how their work relates to the big picture. I often ask engineers why they are (to use your example) rewriting the login system, and is there is any way to quantify the results. This helps to avoid engineers polishing an already-round ball, and to have some kind of accountability for outcomes. If you are rewriting login to cut down on tech support calls or to make it work with third party auth or work with legacy enterprise garbage, all those reasons are tangible and possible to quantify.
The numbers are not the point. In some sense it's exactly to weed out those who cannot just say A or B and stop at "well if you look at it like this then A, but perhaps B...". It's 12%, and that's it. You signal that you care about making money for your boss, which, however we twist it, is the reason and hope behind every hire.
Its a cultural thing. They fear ending up with a bunch of people who just want to have fun with elegant code and tech and polish some corner of the app for a esthetic satisfaction. They fear not even being able to communicate effectively about your role in the business.
Being able to say 12% is much better than not even thinking of trying to estimate it. Theoretically, a nuanced view would be even better but there is a time and place to be nuanced and witty and thats not on the HR desk.
> if you are a cashier at McDonald's, you can technically say that you "process high-frequency cash transactions for multi-billion dollar company on rotating supply-demand cycle"
I'm not sure this is technically accurate. The transactions a cashier at McDonald's handles would usually be "for" the franchise where they work, not for McDonald's itself.
Replace it with Walmart, or imagine it is for someone who worked for one of the 7% of MacDonald's locations that are not franchised. The point still stands.
Very valid counterpoint. It could by HN's latent bias against marketing types (in the dismissive sense) as the GP is the top comment (as of now). There's a difference between clickbait and trying to convey the gist of an article with limited chars (and thereby triggering the reader's bias).
The article makes it clear from the outset that:
1. She was in a very junior position and was cold calling clients before EoL-ing an embedded DB product
2. She delivered the insight to key executives in a way that prompted a product positioning pivot that turned out very lucrative (even if the $1B is disputed the circumstantial information seems to support it - parent company's valuation/revenue and the fact that the product still exists within a larger company).
3. Her track record speaks for itself (so it's not an anomaly) but this experience is also her origin story.
I think a energetic butterfly was more responsible for the $1 billion in revenue.
But on a serious note, this is clickbait. Anything that says "X happened, then ${big money}" is designed to trigger "X happened, if and only if ${big money}" in peoples minds, and therefore "X is the secret to ${big money}" so I need to find out that secret to big wealth, so I will read the article. It's bait.
The expletive was tongue-in-cheek, in reference to the publication (How the F*ck). If that's missed then I can see how the post could seem like an angry rant. (It isn't.)
Wow, at no point did I get the impression that she was responsible for the whole thing. Yeah, the title made me think she was going to be more responsible, but nothing wrong with pulling people in and I was very satisfied with her explanation and story.
And the story is awesome! It points to how sometimes getting the product into as many hands as possible and then interviewing customers on how they use it a great technique for eventual product success.
She probably could have talked about the engineering side a bit more, but she probably just wasn't in the loop there. And anyways, this is obviously a marketing blog post so engineering would have been a pointless diversion.
Btw, I got the sense she was enthusiastic and energetic and likely very diligent in her efforts to call up her customers and get to the root of how they used it.
Don't underestimate that level of ground floor contribution.
Is this sort of thing not pretty normal for basically all business writing? It's meant to get traffic inside echo chambers like LinkedIn, not actually help people.
Perhaps, but it seems a lot of this is basically building public profiles to gain credibility (and build your network) to apply for c-level jobs, more than anything else.
I helped conceive, and managed, a product that handled $1B revenue per month at a single customer site (and was installed at many more). You don't see me going around and bragging about it (oh wait...)
Funny enough, the significance went completely over my head at the time. We were too focused on making sure it worked and not losing any deposits. It wasn't until a year later when I ran some stats for a product review / presentation that it sank in.
April Dunford's book, Obviously Awesome, is very good and worth reading if you're a founder or marketer (or both.) We reverse engineered her workshop and did it as a team at the end of last year for my startup. Was very much worth the day.
Second this - it’s a great book, and one of the few truly actionable guides to doing positioning (a lot of them get pretty academic).
Accessible to founders, and helps lay out the art and science of positioning, and give a methodology for actually doing it. Would recommend it also to technical people who are sceptical of marketing in general.
Do you have any similar books that you would recommend? I am always looking for good marketing books but these days it's all some guru trying to sell their book so hard to identify the solid through the noise.
Josh Kaufman's 'Your Personal MBA' is excellent - its rare that you have one book which goes through all of targeting, segmentation, positioning, marketing planning, and how it all sits together. Often books will focus on one small piece (like positioning, or value propositions) but without understanding how these pieces sit into the wider whole it's hard to put them to really effective use.
Byron Sharp's How Brands Grow is also a great book from one of the world's leading marketing professors, and aims to lay out some iron laws about buying behaviour. Byron is quite a spiky and contrarian personality, which makes the book a lot of fun to read, but he also really knows his stuff.
Second the recommendation. Came across her on twitter last week, found the book & listened to most of it over the Memorial day weekend via an audiobook.
I'm going to give a lot of credit to April for this, and say the title is not click-bait.
Long before sqlite, or CouchBase, there was SQL Anywhere.
And SQL Anywhere had something in the 90's that's still rare even today - hands-off built-in production-ready replication.
(MySQL struggled for a decade to ship reliable replication after Yahoo paid them $40k for the original statement-based replication, and Postgres still doesn't have a great story out of the box.)
It's that multi-source production-ready replication that April shone a spotlight on that made Sybase worth $5.8 billion when it was sold to SAP.
I’d say the main contemporary competitors were Interbase (Firebird) and Jet. Jet couldn’t safely support a multithreaded program, it had to run in an “apartment” and communicate through a message loop. I didn’t play with Interbase at the time but it was preferred by Borland devs. But I enjoyed using SQL Anywhere and found it very full featured for such a small engine.
I worked on some systems in the 90's that used Sybase SQL Server (AKA Adaptive Server Enterprise, not the Anywhere version.) Maybe "Anywhere" is okay, but you'd be laughed at if you suggested using Sybase SQL for a project these days. It's legacy tech.
SQL Anywhere is also legacy tech, but so is MySQL 5.x and lots of other established stuff. Sybase SQL Server was a real contender for a long time and IIRC shares a lineage with Microsoft SQL Server. All the major SQL vendors maintain a huge legacy of design dead ends that they have to continue supporting because applications were built when they were the next big thing.
I used this software in its prime back in ‘97 and it was quite clever. It had none of the problems of its main competitor, Microsoft Jet (Access). MSDE was still a few years away. Plus, it was cross platform, so us Microsoft haters could get behind it, even if we felt forced to develop for the MS platform.
> Sybase SQL for a project these days. It's legacy tech.
1) SQL Anywhere is not "Sybase SQL." Different products, with SQL Anywhere being an embedded database that can run on a smartphone and replicate bidirectionally to other masters.
Not many alternatives, even in 2020.
2) Legacy tech - when you care about your data, accept nothing less.
Fun fact: the #1 most popular and regarded RDBMS for the past few years is considered to be MySQL, and it was the key technology that powered both Web 1.0 and 2.0. If that's legacy, I want more legacy.
Early on, MySQL was known for anything but caring about your data. I've been using it since the 90's. Without "strict" mode, fields would be truncated and data types would be silently converted. Never mind the <5.x days where MyISAM was the default table type.
This happened at the first start-up I worked at, 3 years in and almost bankrupt, one large customer kept using the product for a different reason ( kinda hacking it all together), so we completely pivoted to survive with this customers needs and it became a huge success. That pivot was towards such a niche market that no one was really in the space, and no one outside it would have really even know about it.
It was the year 1999, remember that? I was working at a startup and we were preparing to IPO. I got a cold call from a - I kid you not - "Color Consultant"; I don't know why but I listened to her instead of hanging up, her spiel was:
"Do you know [Inser name of recent IPO]? Well they hired me and I changed the color of their corporate identity from Black on Green to Green on Black; well 4 months later they IPO's raising $250 million at a $1+ billion-dollar valuation".
WUT?
Her implication was that she was taking credit for the successful IPO.
So, there it is.
I am not saying that April's contribution was not useful, but... everything in a long process is useful, but not 1 single contribution is responsible for the entire (or majority) of success. Except for grit!
This reminds me of an early job. It was my first job as a mechanical engineer. I was lucky enough to work in a R&D team on an entirely new product line. Crazy but rewarding work from months on end. Near completion, I was moved to a side team to help out with other smaller projects. At this point the marketing guy comes in to decide on the name and color of the machine. So they bring in the consultants and in the end decided to stay with the name the engineers gave it and the same color as older machines (beige and black.) And the kicker was at the launch party they forget to invite me but invited the marketing guy who spent a couple days helping out. What a punch in the guts it was.
I've been in more than one meeting where, after lengthy discussion about product name, the group circled again back to the original (temporary) name created by the developers.
And in that time it had somehow subtly become adopted by marketing as theirs :)
(To be fair, picking names is hard, even if you are in marketing. I'm sure there's plenty of science, but one of the best ways IMO is to just blather them all around for a while and see what feels right/sticks after a day or two).
Not sure why you're downvoted. I completely agree. I couldn't get past the first answer because of the italics. Why would someone do that. I'm sure it's an interesting Q&A, but I just can't read it.
I did my first internship working at Sybase on SQL Anywhere. Some great people worked at that office. Even some of the original Watcom guys were still there.
Fun fact: SQL Anywhere was still compiled using Watcom C++ long after the latter was discontinued as a commercial product. Most of the people who worked on the compiler still worked there, so they maintained it internally until SQL Anywhere finally switched over to MSVC.
SQL Anywhere was wonderful, but Watcom C++ was horrible!
When Sybase bought SQL Anywhere the compiler came along with it, hence was adopted as the in-house standard. As I recall the debugger would fail regularly due to pointer bugs corrupting the debugger itself. That's exactly when you would like the debugger to stick around... ;-)
It looks like the product was conceived in 1992, Watcom was first acquired in 1994 by Powersoft, which was bought by Sybase in 1995. SAP bought Sybase in 2010.
I'd bet the product has seen significant growth in the mobile / IoT era. Applications that work offline and synchronizes later are a pain to build. Seems like the kind of infrastructure that exists in every police car these days.
Despite the promise of Starlink of pervasive internet connection, there are always blind spots where connection just do not exist or just pain intermittent.
Personally I think the future of desktop applications should be designed around the premise of localhost first and cloud second. The ability of the locally host application to synchronize to the cloud or central repository (similar to rsync and Git) should be the default not the other way around (I am looking at you Microsoft Teams). Technically there should be no different between people working independently with their local copy of data to be merged centrally later, and an offline application with an intermittent internet connection.
Now with readily available VPN tools like Wireguard becoming more popular the notion of using web applications for distributed authoring and collaboration, etc, is not necessary anymore. But if you insist to use web based technology there is always protocol like webdav to the rescue. If you do not want either of them (VPN and webdav), the recently announced SMB over QUIC can be a very good alternative solution [1].
Sybase was really dying on the vine probably at that point, so SAP buying them gave the product a better chance of actually being developed and not abandoned, so that probably helped a lot to boost sales and support contracts.
I remember where I work, the product went from 'divest' to 'retain' following the acquisition.
I think that the talk here about taking the credit for the 1 billion is missing the point. What I think she wanted to emphasize is that they almost shut down a product that made more than 1 billion, and that she took part in the process that saved it.
I think a lot of the discussion in here is about how whoever wrote the title managed to destroy any chance of this interview getting any meaningful discussion. Which I think is appropriate, because it's a blog about marketing that manages to market their blog about marketing with the kind of deftness I expect from my 8 year old daughter's rendition of Let it go.
tl;dr version - Desktop DB product. She called customers, found most were not using, one was and was crazy about the product. Product "repositioned" around that use case. End of story.
I am sure there is a lot more to Dunford's book that this article reveals but IMHO product positioning is the wrong takeaway.
Product positioning, which sounds management consultancy speak like "product strategy" is top-down. Implies near perfect knowledge of the marketplace, customer use cases, existing alternatives..... Anti-thetical, if not opposite, to the Lean Startup method. Lean implies you have incomplete information but you map out the profitable niches by experimentation. You want to build that which is needed, not build and position it later.
Recommend Robert Fitzpatrick's Mom test instead. http://momtestbook.com/. He also has an youtube channel.
SQL Anywhere was an amazing product. What's left out in the article is that it was also really fast.
I had an assignment in 1998 to benchmark it against another pocket database. SQL Anywhere was 100x faster. On the Excel throughput graphs I had to use right and left Y axes for each product. Otherwise product #2 was just a flat line on the X axis. ;-)
This is a strange story. Did the company really believe there was a large market of people who "had to manipulate some data and write structured queries, but you didn't want to do it in Excel"? What was the actual incentive or opportunity that the product was meant to fill? Did anyone acknowledge the popularity of dBase, FoxPro, FileMaker (with Access coming soon)? What was the product failing to do for the 90% of customers who bought it then abandoned it, surely some common themes must have arisen via all her cold calls -- and why didn't they address those issues? On the other hand, Oracle compatibility and sync surely weren't trivial to build, how were these features not already a major part of the marketing strategy?
April is terrific, and I agree that the right messaging and positioning can have disproportionately high impacts on revenue (speaking from experience with Netlify, Gravitational, and others), but this click-bait title is a huge disservice to April, other marketers, and founders who may be dissuaded from trying new messaging and positioning.
The actual story is that the person (April) was asked by a manager to interview a bunch of customers. When they brought back the data, the manager (or the team, collectively) acted on it by coming up with new product positioning.
Some years later, after countless product iterations and three acquisitions, the product landed at a tech giant that does $30B/year. The author speculates it was then responsible for $1B in revenue, though doesn't know for sure.
So...
It's fair to say "I was there early and it was neat to solve these problems for a DB that later ended up at SAP." But to imply that your work directly resulted to $1B in revenue--as this title does--is just nonsense. What the F*ck were the editors thinking.