Starbucks has around $1.6 billion in stored value card liabilities outstanding. This represents the sum of all physical gift cards held in customer’s wallets as well as the digital value of electronic balances held in the Starbucks Mobile App.* It amounts to ~6% of all of the company’s liabilities.
This is a pretty incredible number. Stored value card liabilities are the money that you, oh loyal Starbucks customer, use to buy coffee. What you might not realize is that these balances simultaneously function as a loan to Starbucks. Starbucks doesn’t pay any interest on balances held in the Starbucks app or gift cards. You, the loyal customer, are providing the company with free debt.
And I thought Starbucks sold coffee (average coffee). The more I read, it feels like they are a bank (unregulated) where we have loaned them money for an interest rate of a free coffee every 120 points.
Wordle was acquired from its creator, Josh Wardle, a software engineer in Brooklyn, for a price “in the low seven figures,” The Times said. The company said the game would initially remain free to new and existing players.
I’m very happy for Josh Wardle, especially after the twitter-verse got behind him to take down all the copy cats, but this news hits hard. Guess we will find out how much we pay to play this game once a day.
If you heard “5G”, “airlines” and “problem” and trying to figure out what is going on. You are not alone. James Fallows wrote a wonderful FAQ style article explaining what’s happening between the airlines and the wireless companies who operate 5G.
Short version: 5G versus the airlines is potentially a real issue, rather than a bogus threat. But it’s likely that the parties involved will work out adjustments soon. Which is a good thing.
Head over to the link to understand what exactly happened. I think the regulators have their hands full to read and probably re-write the rules.
I loved reading this article particularly because he simply uses quotes from former CEO’s who have focused on people rather than processes to scale new heights for their product.
My favorite quote here is from Reid Hastings talking about Netflix:
“[The reason Netflix has been so successful is because it has] a culture that values people over process, emphasizes innovation over efficiency, and has very few controls. Our culture, which focuses on achieving top performance with talent density and leading employees with context not control, has allowed us to continually grow and change as the world, and our members’ needs, have likewise morphed around us.”
You need people to continue scaling your product which simply means creation of new software, hardware, service, etc
I came across this great article by Gunnar Morling and have been wanting to repost this for a while… better late then never.
So what makes a good error message then? To me, it boils down to three pieces of information which should be conveyed by an error message:
Context: What led to the error? What was the code trying to do when it failed? The error itself: What exactly failed? Mitigation: What needs to be done in order to overcome the error?
The reason I find this article get is cause its coming from a Software Developer keeping other developers in context. I have worked as a Product Manager & a UX professional for several years now and Error messages is one of those areas which does not get much attention.
Its always at the back of your mind but other important aspects take over and error messages typically get overlooked.
Good error messages are important. When things go wrong, these error messages are the only communication channel between your software and customer. A good error message will allow your customer to recover well or submit a support ticket – and thats $ we are talking about.
The first comment by RossVertizan on this blog also has an important aspect for good error messages:
One thing that I would add is an indication of severity. Personally, I like to have every message preceded with a word which indicates the severity of the message
It seems that Apple has quietly added a new tool in macOS Monterey for measuring your device’s Internet connectivity quality. You can simply call the executable networkQuality, which executes the following tests:
– Upload/download capacity (your Tx/Rx bandwidth essentially) – Upload/download flows, this seems to be the number of test packets used for the responsiveness tests – Upload/download responsiveness measured in Roundtrips Per Minute (RPM), which according to Apple, is the number of sequential round-trips, or transactions, a network can do in one minute under normal working conditions
When it comes to adding a feature to your product, there are countless ways of doing this – and we still mess it up. However, when it comes to killing a feature there isn’t much out there.
As product managers we get excited to take the product to the next level with new features. But deep inside we know there are some features in your product that simply don’t work anymore. You are tracking your product with countless KPIs and metrics to see the health of your product, and its right on the dashboard when a feature isn’t getting clicks or for that matter appreciation (feedback). We either ignore them or simply stop tracking them.
Features that don’t work cost money to support. Worst, just by being present in the product they complicate workflows and risk distracting your users from their core tasks.
You may have heard your customers complain at times: “Your product is to complicated or bulky”. There is a high likely hood that there are features sitting in your product that isn’t being used that’s adding to this bulk and complexity.
Removing a feature isn’t simple. You can’t simply release a new version without a feature. You have to treat removing a feature the same way as adding a new feature to the product:
does the existing feature align with your overall product vision & strategy.
deprecating a feature needs user search, interviews and analysis.
deprecating a feature needs planning, included in the roadmap, and communicate with your users.
To decide if a feature needs to be deprecated:
check with your users what are they using to solve their problems instead of your feature.
did the feature miss the market?
the feature may solve a user problem but its unsustainable for you.
the feature solves a problem for a very small set of users, but its not a problem worth solving for you.
When deprecating a feature, communication and transparency is key. Ensure you have two set paths, i.e. End of Life (EoL) and End of Support (EoS) and there is sufficient time for the users (if any) to move to other options if they are using this feature.
To ensure a successful EoL and EoS,
remove the feature so that new users do not have access to this
de-emphasize the feature in the UI – out of sight out of mind.
suggest alternatives and help your users migrate
Lastly, make sure this is part of your continuous onboarding strategy, where you are communicating this to your users and helping them migrate through the EoL and EoS timeframe.
GitHub CEO Nat Friedman is stepping down from his role on November 15 to become the Chairman Emeritus of the Microsoft-owned service. Thomas Dohmke, who only recently became GitHub’s chief product officer, will step into the CEO role.
Great to see a product person stepping into the shoes of a CEO.
Tesla’s Supercharger network is often held up as the best possible example of an EV charging network: fast, reliable, and plentiful. But Tesla’s network is also exclusive to Tesla owners, meaning someone driving a Volkswagen or Ford EV wouldn’t be able to use it. But that’s now starting to change.
So how long until we start hearing about standardized car chargers?
Toxiproxy is a framework for simulating network conditions. It’s made specifically to work in testing, CI and development environments, supporting deterministic tampering with connections, but with support for randomized chaos and customization.
This is a good library to have in your arsenal whether you are an Engineer, PM or QA. Testing on different network conditions is important.
Thinking ahead to next quarter, consider collaborating with your fellow designers, researchers, and content strategists to develop a UX roadmap. This will prompt you to review potential work against user and business goals and prioritize the most important items. From there, you can share your draft with key stakeholders and see if they agree. Developing and refining this roadmap will help you become more strategic and focused, while helping you develop your collective perspective and voice.
Its not easy to change the culture of how things are built. It’s hard but its important to start doing this.
Agile and lean are all-the-rage and de rigueur in modern software development. The next statement will probably be an unfashionable one but agile isn’t the only way to build web products and waterfall isn’t evil. Product managers shouldn’t be wedded to cult agile.
This made me chuckle. Good read.
First companies and now cities battling for top talent. Good times.
As a product manager by trade, I don’t need sit and learn programming languages as I’m not expected to site down and write code. But the engineering in me wants to keep building.
Looking at data is a big part of my day-to-day work. You might have a data analyst to help you with this, but the analysis of the data and understanding you get of your customer is not something you can delegate. Thus, most cases I take matter into my hands.
Now there is only so much SQL queries you can write and run daily. At some point in time you want to store these values and trend over time. Chances are you have system that will do the job for you, but when you don’t you take matters at hand.
Python was a go to choice, but I wanted to build a cli tool that would allow me to run cURL like commands to an API and capture some of the timing metrics as well. At times I would have 100’s of URL’s that I did like to check.
I also wanted to pull RUM data from our vendor tool for pages of my SaaS application and correlate that data that I pulled from the database.
I had Grafana and MySQL set up to view this data, but I needed something that would run my queries, cURL my API endpoints and pull data from 3rd party application into this MySQL database.
After talking to a few friends, I looked into golang as a means to do whatever automation I needed to do at my end. One of the biggest reason to consider golang was the concurrency – easy to understand and implement.
I have a full fledged system set up today that allows me to look into trends in my SaaS applications with multiple data sources contributing to these dashboards. Here are a few links I used to get myself started into golang.
Go by Example – https://gobyexample.com Literally from basics. I read this just to get a hang on their syntax and how to structure code.
The Go+ language for engineering, STEM education, and data science – https://github.com/goplus/gop Yet another library that cuts down the learning by focusing on the most basics of things. Really good library.
How to write go code – https://golang.org/doc/code When you first start writing go code and everything is in a single file; it woks like magic. When you start separating your layers, is when you get into trouble. This tutorial form Google was one of the best to get me started and understanding how to structure my code.
How to create a CLI in golang with cobra – https://towardsdatascience.com/how-to-create-a-cli-in-golang-with-cobra-d729641c7177 I wanted to build a CLI tool and there is no better library then cobra and viper. I have no moved away from these libraries and build everything thats available in golang; but these libraries will get you started quickly and also help you understand how to build cli tolls and read settings from a config file.
It is always good to refer to codebases as well to get an understanding of how to structure your code or to simply see deeding patters. Some code bases I looked into were Kubernetes and Elastic’s Beats.