Viable > Lovable

The term "viable" (as in Minimum Viable Product or MVP) may be the least understood term in software development. In common parlance, an MVP is often used to describe something that sucks but may get better. This negative connotation causes many to prefer the term Minimum Lovable Product (MLP). "Viable," as it is often understood, means unlovable.

I would like to redeem the word "viable" because it has a lot more to offer than lovable. I think of viable as having some kind of advantage that would make a customer choose it over another option (either a competing product or making do without it).

Thinking about viability in this way helps you ask better questions to understand the value of the solution. What problem are we solving and are customers motivated to solve it? What alternatives are there? Why is this solution better?

Viability in a mature market is very different than in a new category. In a mature market, viability depends on differentiation: a new approach, a different price point, etc. In a new category, viability depends on customers relating to the problem and understanding the benefits of solving it in an innovative way.

The company behind the solution also factors into its viability. For a portfolio software company (that sells many solutions into an enterprise) viability for a product could mean being almost as good as a best of breed choice -- appealing to customers who want the simplicity or savings of a single vendor. For example, most users prefer Slack and Zoom but enterprises often buy MS Teams. Startups have a higher viability bar. Their solution needs to be appealing enough to overcome any concerns about the instability of the company or friction from dealing with another vendor.

Pricing factors into viability. People will not invest in a costly solution to a minor problem.

We lose all of this nuance when we talk about "lovable." A viable product can still be lovable but what makes a product successful is its viability.

The End of Blogging

A bulk of my information diet these days comes from email newsletters. I subscribe to newsletters from news publishers like Axios and the New York times and also personal newsletters from individual commentators. Between personal and professional topics, I probably spend 30+ minutes a day reading newsletters. I don't see RSS feeds promoted as prominently any more. People and organizations have moved their blogging energy to newsletters, LinkedIn articles, or long threads on microblogging networks.

While I feel validated by proof supporting my "Email is the Portal" hypothesis, I am sad that blogging and syndication seems to be disappearing. I like the blogging/syndication model because everyone gets to own a little space on the internet (their blog) and tools (RSS readers) to aggregate content from everyone else's spaces. The system is simple, elegant, and flexible. Everyone has agency to control their content and choose their tools.

The systems that have supplanted the blogging/syndication ecosystem are clearly inferior for the purposes of managing, publishing, and preserving content. In these alternatives, content has no permanent place. You are not going to know about issues from before you subscribed to an email newsletter. Content in an activity feed basically disappears and it's hard to get back to. Thankfully Evernote allows me to store copies of these artifacts.

But the new tools are better for building and measuring audiences because subscription is built into the publisher side of the system. In the blogging/syndication model, the subscriber used their feed reader to subscribe and the publisher needed hacks like FeedBurner and web analytics packages to identify and measure their audiences. With email newsletters, subscribers must provide their email address (and maybe pay money) to get content. On the social media platforms, the audience needs to click the follow button to add their identity to the list of followers.

In this new world, content is an ephemeral input to build an audience. I am not too much of an idealist to realize that the money behind the digital economy always wanted an audience-oriented, rather than content-oriented, ecosystem. People have been talking about "monetizing eyeballs" for decades. But, for someone who loves content (creating, managing, collecting, consuming... all the things), the commoditization hurts just a little bit.

Note... with this post, I have met my 2023 goal to blog every month!

Daily Journal Experiment

Today I started an experiment to keep a daily journal through the end of the year. The first entry (reposted below) explains why and how. I am cross posting here for some additional accountability. I know that there will be days when I want to skip. I am hoping that the possibility of someone asking about my experiment will help me push through.

2023-11-22 Personal Journal Experiment

With this entry, I am starting an experiment to keep a daily personal journal. My goal is to establish and maintain a habit that will: 1) Make writing easier. The more you do anything, the easier it gets. With writing, practice helps me establish my voice and organize my thoughts. 2) Cultivate my ideas and creativity. I am happiest when my head is full of ideas. But often thoughts pass before I get around to explore and elaborate them to the point where they are worth sharing with others. 3) Encourage myself to reflect on my experiences. I don't learn from experience. I learn from thinking about what I experience. Reflection gives me an opportunity to associate my experience with greater context.

How will I do it?

Since, I am already a Bullet Journal devotee, I will add raw thoughts to my Daily Log. I will block off 30 minutes at the end of each day to write an entry in Evernote (one note per entry). Some of the entries will be refined, expanded, or combined for posts on my public blog.

Why don't I suck it up and post on my public blog every day?

I'm too chicken. I want a safe space to play with ideas that I might disagree with a day later.

Why not use one of those cool journalling apps?

I want to leverage the tools and habits that I already have and I want the content to be integrated with the rest of my life rather than fragmented in some other place.

How polished will the journal entries be?

Journal entries will be polished enough to give voice to an idea. They should be "conversation quality:" coherent enough to share with a friend that is interested in the same topic. No fever dream rambles or short hand notes.

How long will I do this?

I am going to pilot the daily journal until the end of 2023. If it achieves the benefits listed above (or some other values that I don't expect), I will create a 2024 goal to continue.

Amazon: The Good Parts

I have been reflecting on my Amazon experience and, while the company has plenty of issues that I am happy to be free of, there are a few practices that I plan to take forward in my career.

Writing Culture

You may have heard about Amazon’s “peculiar” meeting style where the first half of the meeting is spent silently reading a document and the rest is for discussion. Writing out ideas is so much more effective than talking through bullet points on a slide or having a free form discussion. The writer is forced to think through their recommendation, fill in gaps, and fully support assertions with data. Clear writing requires clear thinking. While a deft speaker can gloss over inconsistencies or ambiguity, those deficiencies have nowhere to hide in a document. Documents accelerate the decision making process by organizing all of the inputs and making sure all of the decision makers are fully informed. A good document anticipates skepticism and brings supporting information into the conversation rather than requiring a follow up. You don't waste any time debating facts or jumping from topic to topic. Often the meeting ends with a decision, or at least a concrete list of factors to address. Plus, the reasoning behind the decision and related commentary is fully archived to revisit later.

Leadership Principles

Amazon’s Leadership Principles are the lingua franca of the organization. All Amazonian’s know the LPs by heart and use them in their reasoning. In a performance review or promotion, a manager might be asked to provide an example of an employee “Diving Deep” or “Inventing and Simplifying.” In a strategy discussion, you might consider which option demonstrates more “Customer Obsession.” The LPs seem simple and obvious on their surface, but you come to appreciate the nuance and tension between them. For example, “Bias for Action,” which might lead you to charge forward with an experiment, can seem in conflict with “Insist on the Highest Standards,” which counsels thoroughness and perfection. The LPs make you think and they give you language to discuss your ideas. As an example of how seriously Amazonian's take the LPs, I remember some great conversations about how the two newest ones ("Strive to be Earth’s Best Employer" and "Success and Scale Bring Broad Responsibility") lack the clarity and guidance of the others. So a group shared revisions that I think are much more useful: "Lead with Empathy" and "Build Sustainably." These versions were never officially adopted but I saved the definitions here.

Hiring

Amazon was aggressively hiring for most of my time there. The process was designed for efficiency and effectiveness. Everyone on the interview team had a plan for what areas they were evaluating. They were responsible for finding supporting and contradictory evidence of proficiency in the areas that they were interviewing for. Interviewers were required to submit their notes and their conclusions (inclined or not inclined to hire) before the review meeting. During the discussion, everyone on the team was expected to challenge unsupported statements from their peers. For example, you couldn't say that the candidate "seemed aloof," you had you give an example where they tolerated substandard work and describe the implications of that behavior. By pushing each other and accepting feedback, the interview teams were able to identify and weed out unconscious bias. I was also impressed that Amazon was able to maintain high standards despite the hiring frenzy that all of the big tech companies were engaged in.

Amazon is a huge company and some groups only go through the motions rather than get the full benefit of these mechanisms. But the fact that everyone at Amazon is trained to use them is an incredible strength for an organization if leaders are able to walk the walk.

Twitter Archive Unboxing

Back in December, I decided to leave Twitter X and direct my social energies elsewhere. Part of my emigration plan was to export my tweets in case I ever wanted to access them. After a few ignored requests, X finally generated an export that I was able to download. This is a summary of my experience.

I was never a prolific tweeter (less than 5,000 posts since 2008) so I was suprized by the size of the archive: 45MB compressed. The zip expands into a directory that contains a local website of all of your twitter activity.

The tweets view allows you to browse, filter, and search your tweets, retweets, and replies. All of the images referenced in your posts are stored locally. That explains why the archive is so big. Clicking on the tweet takes you to the tweet on twitter.com.

The likes view is my favorite mainly because I tended to ❤️ jokes. The personalization view shows how Twitter interpreted my interests from my activity to build my own personal echo chamber.

Under the hood, the archive stores all of the tweets in a single JSON file (data/tweets.js) that has high potential for harvesting programmatically because it is so nicely structured. For example, I could easily write a script that ranked my tweets by how many times they were retweeted.

But I probably won't.

While I am impressed by the design and capabilities of the archive, I am disappointed by the utility of having it. Maybe if I was a great comedian, this could be my highlight reel. Most of my tweets, however, were parts of conversations, which are meaningless without the context of the thread. Quoted tweets and retweets also lack context because the original tweet is truncated. The worst problem is that nothing is particularly relevant right now. The moment has passed. The external links have rotted away. For me, the best part was the community and the interaction. And that can't be exported.

For what it's worth, I have the exact opposite experience with this blog, which I started back in 2004. I regularly go back and read old posts to remind myself of something that I learned or how I thought about a topic. You need more than 140 (or even 280) characters to present an idea that can stand on its own. Because I was writing for a public audience, I made an effort to provide context, think and write clearly, and support my reasoning. Being a decade+ older than I was when I wrote many of these posts, I see that I could be the stranger that I was writing for.

RTO Mandates

Here is an interesting Fortune Magazine article about the backlash to Return to Office (RTO) mandates: "We’re now finding out the damaging results of the mandated return to the office–and it’s worse than we thought". In addition to the inconvenience of getting to an office and the inflexibility of not being able to interlace small home tasks in your work day, this article made me think of the “mandate” aspect. Edicts like these send the message that the employee is less valued for what they can achieve than for doing tasks in compliant ways. The top down nature shows how little power the management chain has to support the team and advocate for individuals.

Virtual Talent Advantage

With their "return to office" mandates, many companies are signaling an inability to adapt their culture and/or processes to effectively manage a remote workforce. There is a significant population of employees who have thrived while working remotely and are unwilling or unable to go back to a traditional office setting. For example, an employee may live in different part of the world, their commute may be too long, they may need a more flexible workday, an office setting may aggravate mental health issues or subject them to discrimination or biases, they may have a disability and their home office offers better accommodations... the list goes on. This is great news for companies who are able to "crack the virtual code" because the "RTO" trend gives them access to talent that they could not otherwise lure away from "Blue Chip" employers. Many of the people who are searching for remote work are doing so because they perform better remotely and employers will benefit if they can tap into this talent pool.

So how to crack the code? Here is my quick list of company characteristics that are conducive to supporting a healthy and productive virtual culture.

• Aligned Strategy and Goals. In their book Extreme Ownership, Jocko Willing and Leif Babin talk about how effective leaders are able to communicate goals, set parameters and expectations, and empower people to execute. It helps for a leader to welcome doubt and an opportunity convince their team on the thinking behind the strategy so team members can make better decisions and align others. When someone believes in the strategy and goals, they become internally motivated to act independently and can adapt to changing information. They don't need as much supervision to get results. They don't go through the motions or waste time on superficial expressions of dedication (like face time in the office).
• No Hybrid Teams. While a company can be "hybrid" (part colocated, part distributed), a team should be either colocated or distributed. Sprinkling remote workers into a colocated team creates communication gaps and unhealthy dynamics. When a team is fully distributed, they use tools and build mechanisms that are optimized for virtual collaboration.
• Content Culture. Distributed workers can't rely on peers being available to answer questions during every one of their working hours. Instead, they need to be able to rely on "content" (documentation, notes, plans, updates...) that can be shared across space and time. Distributed workers need effective writing skills to produce assets that will become the ground truth and shared understanding of the team. And there needs to be a culture that values the availability and accuracy of documented information.
• Social Effort. Social connection doesn't necessarily depend on continuous physical proximity. People can coexist for years without even learning each others' names. Whether you are colocated or distributed, you need to intentionally reach out to connect and build trust. When your team is distributed, you need to be more intentional because you don't have constant access to body language and other signals. This includes checking in on each other because silence can mean many things. It's also important to schedule periodic get togethers for team building. Pro-tip: going to a conference with your team is a great way to learn, socialize, and get energized by new ideas.
• Recruit Experience. Organizations that hire entry level staff and practice "up or out" career management often struggle with the remote model. New graduates need highly visible role models and professional socialization that is harder to get in a remote setting. Coaching needs to be more interactive and personalized. Young professionals also tend to have less of a network or community for emotional support. On the other hand, workers who already have a professional foundation and are looking for remote positions have probably already established family and community that they need to balance with work.

AI and Content Licensing

In my last re-platforming of this blog, I accidentally dropped the Creative Commons Attribution licensing that I had been using. Blogging platforms treat licensing as part of the format rather than the content itself. The format is part of the CMS theme so when the CMS changes, the content moves but the licensing does not. I am still trying to make up my mind as to whether I think that is a good thing. But at the moment, I am thinking about the broader issue of content re-use and attribution in light of being used as AI training data.

People publish content for a variety of reasons. Personally, I write to explore and refine ideas and also for the potential to discuss these topics with people who stumble across my posts (although that rarely happens). There is also a recognition element. My blog is where people can associate me with what I know and think. Many websites and communities are built around the value of recognition. For example, sites like Stack Overflow have a culture around recognizing and rewarding expertise.

I have been using the Creative Commons Attribution license because I want people to use and further my ideas and I also want to be part of the ongoing discussion and evolution of those ideas. Based on the language of the license, I thought it would protect these interests:

"You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use"

But, according to the article "Should CC-Licensed Content be Used to Train AI? It Depends" (by Brigitte Vézina and Sarah Hinchliff Pearson), there is no agreement that any form of copyright applies to AI training.

Large Language Models, trained on terabytes of content (the GPT-4 dataset is 1 petabyte), create new value for content consumers wanting condensed answers. But that intermediation saps value from the content producers and publishers. The ChatGPT user has no idea if some pearl of wisdom came from me (doubtful) and I have no idea if my knowledge was accessed or what became of it.

I think that I will continue to write even though I know my words will be anonymized by AI. I still get the value of using writing to organize my thoughts and to develop my communication skills. Jack Ivers has a great post describing the reasons for writing every day. But I don't think I would be as excited to post answers on Stack Overflow unless I wanted to build adoption for a particular technology that I supported. I am even less likely to post an answer on Quora.

I wonder if AI chatbots will stifle other contributors' motivation. Perhaps it already has but I haven't heard much of an uproar. If generative AI drives the extinction of user generated content (which helps improve AI), the progress of knowledge will slow because it will not be able to incorporate new experiences.

Wikipedia is a bit different. Wikipedia contributors are mainly concerned about the accuracy of the content rather than attribution. In many ways, personal attribution taints the authority of the article with the possibility of bias. Consequently, you have to dig to find who wrote what. Wikipedia is already harvested by search engines and voice assistants (both Alexa and Google Assistant rely heavily on it). The contributors don't seem to mind.

For now, I have re-added a Creative Commons license to the footer of this blog and the syndication feed (Pelican, I might submit a pull request for that). Not that it does any good.

Penetration Rate

A couple of months ago I wrote a post about Retention Rate as the first metric to watch when rolling out a new product or feature. High retention rate is strong evidence of your product's utility and usability. Once you have established this value, it's time to drive adoption.

You measure adoption with penetration rate, which is calculated as the number of active users divided by the total number of potential users. Sometimes there is debate around the scope of the potential user base. I advocate for a broader definition. For example, even if you have only launched in one locale, I think that you should calculate penetration rate against worldwide potential customers. This way, when you launch a new locale, your penentration rate goes up and not down. In general, I like metrics that go up when good things happen rather than ones whose dips can be explained by progress in other areas.

To increase penetration rate, you need to attract new users and keep the ones that you have. You should track both customer acquisition and retention because aggressive customer acquisition can mask churn, which is harmful to your business long term. You don't want to waste resources chasing customers that you can't keep.

Consider the channels you have to build awareness: release notes, tool tips and interactive product tours, searchable documentation, email, youtube channels... But be aware of the annoyance factor, the more accessible (in your face) the channel, the more disruptive it can be when unwanted. My team at Alexa Audio owns the hints that occur during audio playback. Alexa "by the way" hints can be very annoying so we have strict rules for which ones we allow during the audio experience. The hint must introduce a feature or content that is useful in current context. For example, we might suggest how to make a play queue continuous after the music naturally ends.

You need to be scientific in how you measure the impact of an experiment. This means randomized tests with control and treatment groups and the ability to compare immediate and long term behavior of both groups. A high conversion rate is not good if those who got the impression wind up using your product less over the following months.

In addition to building awareness, you need to make sure that the customer's first attempt to use the feature is successful and they experience immediate value. If the feature is not designed for immediate value (like auto-save), show progress toward that value (like showing a last saved time).

Most organizations don't have the analytical capacity to measure and manage penetration rate for every feature in their product. It is best to focus on "high value actions:" features that, when adopted, increase overall engagement with the product and value exchange between you and your customers. There are sophisticated statistical models that can calculate the monetary value of each action but a simpler approach is to segment your user population by overall engagement (such the days in a month that they use the product). Compare the behavior of the top quartile with the bottom quartile and see which features your most active customers love. Then you can build programs to help your less active users discover these features.

Decisions

Decisions, regardless of whether they are right or wrong, are critical for moving an organization forward. Organizations that can't make decisions waste time rehashing the same discussions and eventually wind up going with whatever option was the default. A well managed decision, even if it leads to the wrong option, has value because it draws attention to an issue, allows the organization to act intentionally, and creates an opportunity to learn from the selected course of action to course correct. It's better to make a decision that you can pivot from than to cower in indecision. At Amazon, that's the "Bias for Action" Leadership principle.

To get better at making decisions, organizations should use every decision as an opportunity to improve their process. Once you are aware of the necessity of a decision, I recommend you start your road to improvement by asking the following questions.

1. What decisions do we need to make to move forward?

A decision is only necessary if not making it stops progress. As long as it doesn't slow you down, deferring a decision allows you to make a more informed decision in the future. But be aware of of decisions you are unconsciously making by over-linear thinking that ignores options -- especially those that are hard to reverse.

2. Whose decision is it?

A decision should be made by someone who is accountable for the short and long term success of the impacted component, system, or experience. That person should own all of the relevant dimensions: cost, time to market, usability, viability, etc. The decision maker is also responsible for deciding who needs to be consulted or informed and manage that communication. If someone finds out about a decision and has the authority to question or reverse it after the fact, that's on the decision maker. So the first thing to do is understand the blast radius of the decision. A smaller internal technical design choice could be made by the person maintaining the code. If it has larger implications, the decision maker needs to have a broader scope of accountability.

3. What information is needed to have reasonable confidence?

You will never have complete information about all the implications of all of the potential options. If you did, the choice would be too obvious to even consider it a decision. The threshold for the level of confidence depends on the reversibility of the decision. If reversing a decision has no cost, you might as well just start trying options. But that is never the case because just trying something has the cost of time. The decision maker should be able to articulate up front what data they would need to reduce risk to an acceptable level. Examples include a technical proof of concept demonstrating feasibility, user research using prototypes, a well designed survey with a large enough sample size to achieve statistical significance, revenue or cost projections. Be aware that sometimes the cost of gathering this information outweighs the risk of the decision itself.

4. How will you validate whether you made the right decision?

Decisions shouldn't be fire and forget. Your plan to implement the decision should include instrumentation, monitoring, and attention to the results. Ideally, you should think of thresholds when you should reconsider your choice. For example, if we see a retention rate of less than Y, we will pivot to a different choice. Or time could be part of your threshold. For example, we will run this experiment for 4 weeks and then look at the data. Good decisions should preserve the opportunity to change course. But you need to know when to consider those other options.