CHRISTINA MOORE

Soul of an Internet Machine

07 – Wayfair Wayside

by

Listen to Podcast with Your Favorite Service

By the way, if selling on-line in the United States, you have about 11,000 potential tax payments to calculate monthly or quarterly and you probably don’t know about them.

Brava! Capitalism and democracy are a nearly impossible combination….both vying for a somewhat limited amount of money. Boils down to cleverest schemes for acquiring same. Obviously mathematical training is essential. The algorithm is emperor.
Thank you for a sunny wake up.
Lynda C

Summary

The United States Supreme Court changed the landscape of internet commerce with a 2018 ruling called “South Dakota v Wayfair Inc”. With the stroke of five pens, business had to comply with thousands of sales tax jurisdictions within the United States – up to 58 states and territories, 3,000 counties, 10s of thousands of municipalities all want revenue from internet-based sales. This determination opened businesses to new risks. It created an entirely new business venture called: interstate sales tax compliance service provider. And new phrases such as “SST” for streamlined sales tax process. It will cost small business thousands of dollars to comply. For us, compliance will cost more than the taxes we pay.

Read the episode transcript

The PDF version of transcript is here
Click Here

06 – Recurly

by

Listen to Podcast on Your Favorite Service

Transcript

The internet marketspace emphasizes both self-service and self-reliance. The buyer, you and me, hold a puzzle-piece shaped description of needs. We then strive to find a service provider who can complete the picture. Rarely do I talk with a real human being or get to ask questions. The damned chat windows on sales pages focus on the wrong answers – well certainly not my answers.

But then, some services standout such as Recurly. As a note, they are NOT sponsoring this episode or podcast. We are but a humble customer they have never heard of.

I will identify Recurly’ services, our decisions, and our processes in this chapter. But maybe first, I define Recurly. For PodcastFlow, Recurly replaces PayPal. I divulged a few of our misadventures with PayPal in Chapter 5. Their failures forced us to run away. Recurly promises to be tool to manage credit card payments for subscriptions to our software and our courses. We ask new customers to buy a subscription with a credit card and we do not want to ever deal with the confidential financial data related to the credit card. There are two reasons. First, it makes us a target for bad actors on the web. Second, to collect that sort of financial data means we must comply with a rigorous series of international standards. Frankly, my favorite means of keeping data safe is to limit access to it, even my own.

Recurly’s business model better resembles a fast-food restaurant than a linen-draped place with too-much silverware. I still prefer the professionalism of sit-down dining in comfortable place with wait staff who listen, and teach, and indulge me that little bit. The internet business model provides few opportunities for indulgences and poetic descriptions of savory foods. Instead, our team steps to a figurative service window on the internet with no one at the counter. Both the modern buyer and the modern seller expect little human interaction at this figurative service window. The exchange, occurring at near-light-speed, completes. An old promise of no human touch fulfilled. “Look ma, no hands”.

Our team shifted focus to Recurly in less time than it took to understand the facts, the sort of speed on sees after touching a hot stove; a reflexive twitch. It was after we re-tooled for Recurly that we appreciated our decision, their services, and the full scope of their offerings. PayPal provided the pain and we hit Recurly in the recoil.

I could paint that decision process to tell almost-truthful story – tell a bragging story. Here, in the left column here are the features we want. In the right column, the features Recurly offers. While we did deliberate as a team over a modest pro-con matrix. We did not do anything like this. We knew what we hated (oh, PayPal) and through that experience, learned what we really needed and wanted from a partner.

I can admit that both the PayPal and the Recurly decisions involved more intuition and gut than research.

Recurly ticked off enough features to be the good-enough option. Surprisingly, we accidently found features that resolved long-simmering issues between Kelly and me. We found these features as we wrote the code, not before.

Kelly and I had a kinetic discussion about pricing and features in October of 2019. My position was absolute and solid in structure. On the other hand, Kelly sought flexibility to bundle offerings, offer coupons, and capture analytic data. Her desire for flexibility opposed my understanding of what PayPal could offer. A subscription with PayPal followed a simple rule: X dollars for Y term renewed at Z intervals. To this formula, we can have a trial or no trial.

Kelly wanted pricing that allowed us to sell a course with the software free for six months, then renew the software at an annual rate. Described thus: “six months of software for free”. Buy this and get that, and that too – like late-night knife commercials.

My position: We can only structure offers that we can support with our tools (and our partner’s tools).

Her positions: others do this, why can’t we?

I had to win the conversation. We can only do what the tech permits. I refused to write a full suite of tools for managing payment which may step us into storing payment data such as credit card numbers, expiry dates, and billing postal codes.

As a tool smith, I propped myself on two false pretenses. One, instead of accepting my duty to solve problems, I fought back with: “No”. Second, I then assumed that PayPal had the same capabilities and limitations that its competitors have: Hertz to Avis or Wendy’s to Burger King. As firms compete, their offerings overlap.

I was wrong, again.

We acknowledged the failings with PayPal in June of 2019. By July of 2019, we continued to fight with PayPal. Services and technical documents fell below our expectations. We compensated by limiting our vision and banging at problems with the few tools they offered us. They offered one path forward. We followed it.

In December, our team’s combined frustrations with PayPal pressured us to movement – in the same way that flood waters push on a dam. I had tunnel vision. My tunnel vision infused the team. My explicit and implicit instructions failed to include the freedom to examine other vendors.

When we started the project in June, our intent involved selling subscription-based software to a global market. In December, our offerings expanded to include courses. Our needs changed. PayPal barely met the needs defined in June. Then failed to meet the needs known to us in December.

The needs did not change, only our comprehension of those needs.

The dam broke when our accounting team explained South Dakota v. Wayfair Inc. Vision opened wide; at that moment, my resistance ceased instantly. We shifted focus, wrote a digital connector within a week. The Supreme Court of the United States (SCOTUS) determined that business must collect sales taxes on behalf of every state in the U.S. PayPal can’t do this, not for subscriptions.

A subscription is different than a standard online purchase. Let’s say I am buying tea at my favorite tea shop. I click my Earl Grey, select the one-pound bag. Find my demerara sugar cubes. Sneak-a-peek at some lovely kitch, then order a new tea strainer. I examine my on-line shopping cart. I forgot my tin of Scottish Morn. I find then add that. The shopping cart analogy works well. I have an inventory of items in a basket. The checkout process calculates price based on quantities and unit prices. I have already provided my shipping address to them. They have a subtotal of goods sold. They know my location. The system looks up the taxes. The grocery items are tax exempt in Vermont, the tea strainer is not. The taxes display, then I pay the total amount after selecting my shipping option. This process cycles back and forth between the website and the customer. A digital dialog progresses in the background.

Subscriptions vary from the purchase of a product. The consumer buys annually or monthly. After the first approval, the subsequent purchases run through without additional guidance. The same amount is charged to the credit card at the appropriate interval. There is less back-and-forth between consumer and vendor. To calculate taxes, one must have key ingredients. First, we need to know the location of the buyer. We can approximate this from the shipping address, or the billing address, or the internet address. These sources for location may not agree, therefore a bit of guessing is required. Shipping address is likely more accurate than the billing address. These addresses are both likely more accurate than the internet address.

The process of identifying a consumer’s precise location is an estimate. The town related to my shipping address has my home in Brattleboro Vermont nearly thirty kilometers away. This town collects sales tax on goods. My mailing address, a post box is five kilometers away. My internet address shows up with random locations around Vermont and New Hampshire. When my VPN is running, the internet thinks I am in Ashburn, Virginia.

The precise location matters. Brattleboro Vermont charges additional sales tax. My town does not. But because my shipping postal code appears to be in Brattleboro, we sometimes pay sales tax. My tax rate should be six percent. Instead, it varies between six and seven percent.

The variation results because of challenges in finding a precise location with imperfect data. In the type of software, we write, no one has written syntax for “maybe”. Rules inside of business software involve matching a situation against known criteria. If the postal code is 05301, then the consumer is in Brattleboro Vermont. Oracle database systems resist variations on this such if the postal code is 05301, maybe the customer is Brattleboro Vermont. A software developer faced with resolving this situation must look for more data. The software, nor the software developer can know that the United States Postal Service used the same postal code for five towns covering nearly 1000 square kilometers. We, developers, strive for greater precision with more data.

Often more data obscures. The data fail to align. Instead of a tiny dot on a map, a system paints a vague box of likely locations for my home. Therefore, the developer must then decide whether charging tax or not charging tax is the better course.

In the end, the developer must decide to avoid fines and penalties. Failure to collect taxes may result in fines while collecting taxes where not due may not even be noticed by the consumer. Done. The developer decides to charge the additional one percent and send it all to the State of Vermont. Vermont will send some to the Town of Brattleboro. Therefore, Brattleboro collects sales tax for a transaction between me and my tea vendor in New York. To be entirely clear, I am not in Brattleboro. I did not ship to Brattleboro. Go ahead Brattleboro, enjoy the one percent sales tax collected from my purchases.

Something similar did happen in Boston Massachusetts in 1773, with tea, with taxes on tea. I know that story, I had two third cousins participate in that protest (yes, a few generations back and they were both third cousins).

 

The Ideal Customer

Our decision-making process in December informed me about how I respond to the pressure to buy. I am skeptical. I deny trust to anything advertised or efforts to capture my attention. My eyes scan and my brain filters incredibly fast. There are times that I wonder how anyone sells anything to me. But I buy. Sometimes, I even shop with pleasure. Though, shopping with pleasure is rare. Most often I fill with dread. I frankly hate shopping.  

When I do buy something, I can effuse on the purchase – tell stories, show off a bit. I am a customer that businesses should want. I am an ideal customer (of course, I’ll say that about myself).

I am NOT the customer that business advertise to. I do not fit into demographics of sought-after consumers. I never did. Never once growing up did I sincerely identify with anyone’s target market demographic. They always wanted someone else. In my youth, I did try. Regret, and sadness and frustration often followed my effort to be a customer. I cannot buy clothing off-the-shelf. I feel like a comic book freak sent from section to section, wandering store to store wanting something to fit and look good. As a teenager, each thigh was 71 centimeters. My waist was 66 centimeters. Salespeople pointed to the distance saying: somewhere else. At an awards dinner in the Bay Area back in my Cisco days, a friend told me that my shoes would not do. I nearly cried. I resisted then yielded. Tiina stated with confidence that we will find shoes that fit. We called Marco, my bay-area driver (long before Uber) to support our shopping effort. After six hours, Tiina accepted failure. My mother, then living in Italy, had written me a letter about that time. My mother wrote of herself: I must be Cinderella’s oft sister, there isn’t a shoe in Europe that fits my foot. Our extraordinarily wide feet always put us in the oft position, the other shop, the other place.

Shop attendants informed me in plain words: “We have nothing here for you”.

I have cash money and a problem to solve. But so many businesses have said: No, not you.

Over the decades, retail businesses and I came to a firmer resolution. I could not go to malls and bright stores any longer due to PTSD.

From twenty years of age, I started working on emergency ambulances in and around the cities of Boston and Cambridge, Massachusetts. That work served as my summer job during school, and an easy landing place after my degree. It paid well after some seniority. The job eventually faded to weekend work, then finally no more flashing lights, no more crime scenes, violence, degradation, death, mutilation, and bitter sadness. By the age of 28, my startle response was lethal. I lived on a raw edge due to PTSD. No more holiday firework shows, no more big crowds, no more concerts. And no more brightly colored malls and stores.

Brightly colored lights can at times cause me to shut down to a child-like state. The incapacity it causes starts a cascade of other problems. When like this, I just do not belong with normal people. I feel broken.

I got help. I improved. I learned my triggers. I did eventually return to a few concerts. Yet, shopping malls and big retail stores instill me with fear of my own response.

The poor businesses think they offer happy bright colors, the colors and energy of joy. Yet to some population, it is just too much stimulus – it is all noise.

I spent a year in Iraq in 2006, and then I spent ten years as a paramedic in rural New England, including time as chief of a service, mentor, instructor, and incident commander. I have tools and techniques to assist with managing my PTSD. Twenty-five years of symptoms that wax and wane, inform my basic decisions about shopping, travel, adventure, and fun.

I am not broken!

Nor am I unusual.

The fact I am not the demographic for so many businesses is not my fault but their fault.

I have spent my entire adult life learning to avoid anyone that tells me I must pay attention to them. If you are advertising, I know you are NOT advertising to me. You have already told me that, I am not in your demographic. I have walked into your store and been told: “We have nothing for you here”.

Your crowds, your bright lights, your music will crumble my strength. I will become irrational, fearful, angry, a resentful of being trapped by your walls. Your behavior already tells me that you do not want me, you do not know me.

Guess what, I am an ideal customer. Screw you for not knowing that. And screw you for not figuring out how to sell to me. Know who did? Amazon. Know who else did? Any number of bespoke tailors who know how to shape fabric to fit the human. I can buy a car in a snap. The most recent car happened to have been the most expensive one on the lot, and the most expense model the manufacturer makes. Frankly, I did not care much about the cost. The car fits me (or is it that I fit the car). I am happy to have it.

The ideal consumer is one who has money and looking for a solution or a product.

It is that simple. 

Podcast Flow LLC sells subscription-based software to a global market. We need a solution that helps us manage subscriptions, including payment and regulatory compliance. The cost of the solution will be treated as cost-of-goods-sold. We budgeted PayPal to cost approximately 4% or more of every transaction. Therefore, we have money to fund our solution.

We are an ideal customer.

How to Sell to Me

Selling to me is hard. Fifty years of television ads, fifty years of radio ads, twenty years of internet ads. As a technologist, I know all of the knobs and switches to help me minimize attention-grabbing noise. Throughout my adult life, I could program any device and use the fast-forward button.

For those of you who have ever left a military post at the main gate. The experience can be like arriving in Oz. Across that road are brightly colored signs, big letters, flashing signs, flashing lights. On post, the colors, building shapes, signs, and terrain adhere to color palettes established by Uncle Sam – muted, earth-tones, subtle. Off post, there are fast food joints, bars, pawn shops, and bail bonds. They all scream: Look at me!

I can’t. I can’t see anything in that mess. My basic skills for friend and foe recognition fail. I need to differentiate trust from don’t-trust. I need to tell the difference between signal and noise, a technical term from the old days of radio. Sometimes there is a valuable message in the chaos of static, lights, and mess. That message is the signal. The rest is noise. I need to filter the noise, which is also called squelching.

I instantly squelch red, yellow, flashing, and strobing. I can squelch movement. It’s hard. I can spot an owl land on a tree limb from 100 meters in the pre-dawn light. Clearly, I do not enjoy Las Vegas.

That first measure I make is a trust/don’t trust assessment, also called a threat assessment. How safe am I?

In my first weeks working in the city on an ambulance I learned a new way to knock on a door. Step one – do not stand in front of the door. Step two – knock on door with an outstretched arm, most often with the long flashlight. Step three – understand the person on the inside has already experienced trauma sufficient to call emergency services. In summary, when knocking on a door, my life is at risk.

Dear Vendor: know that some portion of your audience performs an instantaneous threat assignment – often unconsciously and executed with bias beyond your understanding. Please help me with this assessment. How easily can I find your bone fides?

Dear Vendor: please tell me what you offer? Please tell me a clean story, a consistent story. I understand that positioning a new product in an emerging market is difficult. During the 1970s somebody once said: nobody needs a computer on their desktop or in their home. Yet today, so many of us carry mobile computers on our person.

Dear Vendor: please try to avoid stupid mistakes. My criteria and tolerance for creative spelling varies. In a multi-lingual neighborhood, phonetic efforts can be a great hook to grab my attention. On the internet, be professional about language. In 2020, a non-native use of a language on the internet can be warning sign. If you wish to sell to corporate businesses in North American, that typo may signal me you are a fraudster. Conversely, it could also tell me that you are also a left-handed dyslexic like me – thereby fostering accidental kindredship. You can’t know how I’ll respond. Get it right.

Dear Vendor: please provide some depth. Somehow connect to something beyond yourself. Local-town trades person may have a two-page website. Even there, I expect a phone number that make sense and a dot on a map. Please, please find someway to establish a legacy on the internet. If you really can’t, write a heck of an origin story to tell me why I can’t verify you in some respect. You, your idea, your product, and your website didn’t hatch fully formed and ready for business. If it did, you are committing fraud.

Here is a fundamental checklist for selling to a scarred, scared, and skeptical market:

First blink: survive the friend-or-foe threat assessment.

Second blink: tell me what you offer

Third blink: don’t distract me with errors and excessive movement (noise); Be consistent.

If you survive that, then know I will dig. I am about to give you money, maybe my credit card. I may tie my business to yours.

I will triangulate you, your firm, your staff, your products, and your services.

Internet Triangulation

Yes, the first search is absolutely done with one, two, or three internet search engines. No, Google is not alone. Google results are manipulated by revenue to Google, neither good nor bad.

We took Recurly and ran it through popular news aggregation sites and search tools. Multiple sources reported that Recurly raised $19.5 capital during the fall of 2019. That infusion of capital was after our first efforts with Paypal.

Results that adds to credibility:

  • A competitor advertising on top of a search for the target name
  • The target results in the top few listing of the search
  • One or more articles by an independent source – even a hometown newspaper
  • Some hint of multiple links, such as partners, etc
  • Social media hits including blogs.
  • Are there blogs? Do the blogs augment the story? Or distract?
  • Any references to staffing, hiring, leadership? What are the jobs that are posted? What credentials are required for the jobs?
  • Is there a help desk or knowledge base? Can I get to it?

Clearly there are derogatory results that prompt elimination. I can skip that analysis.

Let’s imagine, you are Recurly and you want to sell to me. Your wicked smart marketing team knows everything I have just now written. Let’s review what Recurly is selling. They suggest they have the ability manage subscription payment and renewal for our on-line software. Recurly tells us this in the hidden information in their website header:

Title: Subscription Billing and Recurring Billing Platform | Recurly

Description: Recurly provides enterprise-class subscription management for thousands of businesses worldwide.

That is a near perfect alignment with our statement of needs.

They offer a proof-statement through their dedicated developer’s website. They provide complete documentation of their digital connectors on a website. In this documentation, they provide two additional nibbles of information.

First, they document their entire history of their application programming interface, including data on prior versions.

Second, they provided me a link to download their interface. I am not, my team is not stuck typing stuff from a website and failing due to errors. Recurly met us half-way.  We must still write code but now we have a known and demonstrable target.

The information we discovered on the internet told us that someone else has trusted this company. Someone has invested time, money, and smarts into this company. Their digital interface demonstrated human intelligence and experience in knowing what we would need.

I tell myself that the segregation of the developer’s hub and documentation to a separate website illustrates a negotiated settlement between the marketing people, corporate leadership, and technical people. I fabricate the following in my mind: there is a voice in a meeting stating that the API and technical documentation is a corporate and marketing asset. Another voice in this meeting argues back. No, decision makers will never look. It is just noise that will distract the audience. A third voice states: you can’t share the API publicly because it gives up our intellectual property and gives our competitors an advantage.

Listen to me. I make decisions. I am an ideal customer – for someone. I am not unique. I am not a unicorn. Accept your customers for who they are, not who you want them to be.

Let’s follow my eyes through Recurly’s primary website (as I see it in the Winter of 2020). I see a clean website. There is some small movement of company names fading in and out of a list of supposed customers – some well-known firms and some I’ve never heard of.

I scan this list. There are some firms listed that would defend their brand and kill this website if their name was ill-used. Ok. Tick. Probably not complete lie.

Their website is not screaming at me to pay attention. Their website can sit on my desktop and not distract my eye. I can leave it up. Dozens of websites I visit per day, I must close, bury, or minimize. They flash something. The moment a website moves, I kill it. Boom! Gone. I have three monitors and I want a fourth on my desk. If I give your website real estate on my desk, don’t be the ass that pulls my attention from something more important. You be you. I have you open for a reason. Do a popup, play a video, have stupid moving box follow me down the page… you are gone. I kill you, I close you. Bye bye.

While discussing website animation… let it be purposeful and deliberate. Let it tell a story in the movement, then please make it stop. What goes on in my mind while I am at my desk? I balance between intense focus and head-on-a-swivel distractions. At any second, something critical and urgent may disrupt everything. I have spent fifteen years responding to emergency calls from other people. I spent a year in Iraq building communications infrastructure whilst people fired rifles and mortars somewhere in earshot.

Listen, I am one of millions. If you wish to distract me with movement, make sure you mean it. For example, crashed server, failed services, new urgent trouble ticket, bank balance crashing, a health or welfare issue for friend, family, or colleague. All the rest of y’all: shut up.

As I roll down the Recurly site, I read some of the words on the page. “Powering subscription commerce” hits home with a message. I understand. Good.

“Top Subscription Platform for maximizing revenue” with maximizing revenue in bold. I don’t trust this statement. Top platform is subjective. Maximizing revenue is not their job. They collect money for my firm to manage subscriptions. They don’t sell for me. They don’t market for me. Our revenue rests on my shoulders, not theirs – unless they are in the marketing and sales business as well. Wasted space, wasted words.

Roll down…A list of companies. Oddly Recurly is not claiming them as customers. They just list logos. I just clicked their link to “See all customers”. I am not there, so this statement is not truthful. The truth is worth advocating for. Moving on…

“Subscribe to our philosophy” – ooh clever. But I do not know what it means. I try to click and nothing happens. There is no article or definition. Too bad. Wasted space. Roll on…

I see resources in a region. Helpful. Good. And now a menu with some meat. Here I am at the bottom of the page, having ignored the top 90%. My signal to noise analysis continues as I click through the links. Recurly’s signal-to-noise ratio is on-par with most North American business-to-business websites.

Why did we miss them in June?

I can’t answer well. Recurly did not appear in our quickie analysis of PayPal’s competitors. Furthermore, we searched three months before they got a 19-million-dollar investment. We could have used the wrong search terms. They could have had the wrong keywords on their site. My tunnel vision and focus on a market leader added to the delay in making a better decision.

Furthermore, I am a scared, scarred, and skeptical consumer. That’s a tough market to hit. I firmly believe that if you want my attention, you are wrong because I am not now, nor never have been your demographic. My defenses must have flexibility otherwise, innovation and invention are not possible. I need others. I need to feel some sense of inclusion. I may need your services. Riddle that out, and you’ll win the game.

 

Conclusion

Not only did we write an interface to Recurly that works brilliantly, Recurly continue to improve their services. PodcastFlow intended to launch during the eve of the global COVID pandemic. We hit pause and postponed our effort.

During the ensuing month, Recurly snuck in a nice little feature called “items”. It seems like an obvious feature. Items makes bundling and building subscription plans easier. In the summer of 2020, we modified our digital connector to Recurly to use these items. We then made very real improvement login and security aspects of our products. Recurly’s improvement met new needs for PodcastFlow.

We decided to release more courses for podcasters. We had already written a learning management system with Oracle APEX and PL/SQL. The Learning Management System is attached to PodcastFlow. The two are separate software. With the enhancement at Recurly, now if we see “LMS” in the first part of an item code, we know that the customer bought access to the learning management system. The second part of the code informs us which course or courses to provide access to.

The few weeks of effort improved our services significantly. I have a few criticisms or hopes for Recurly, they are so minor I’ll not share them publicly. Maybe by the time, I record this episode and publish it, they will have made a few fixes. 

In closing, the self-service nature of the internet marketplace means the seller may know little about the actual customer. Store front windows like websites often echo the age, taste, bias, and demographic of the marketing and sales team. Sadly, too few marketing folks recognize that their decisions may be repelling customers with cash.

You know who my perfect demographic for a product or a service that I sell? Or even the perfect demographic for this podcast? Anyone interested. While I do speak about business, entrepreneurship, software development, and business decisions I hope I don’t drive away interest (unless of course, your PayPal. Oh well.)

In the next chapter, I will discuss the United States Supreme Court decision “South Dakota versus Wayfair”. This ruling changed internet commerce in the United States. It had an immediate and profound impact on nearly every business selling anything via the internet to a person in the United States.

05 – PayPal

by

Listen to Podcast on Your Favorite Service

Transcript

Not only did I hold the wrong position, I adhered to it for six months. We knew from the first minutes of working with PayPal they eased themselves comfortably into a legacy position, as rusty as Western Union. Once upon a time, PayPal forged ahead. They guided a granite-build industry into a more fluid digital one. The pedantic amongst us eschew the definition of PayPal as a bank. But they are right, or close enough.

Podcast Flow identified the following needs. First, a means of capturing payment for subscriptions to our software. Second, a smooth interface for a digital connector. Third, a trusted household name. Fourth, a partner for sharing the challenges of regulatory compliance

For the best part of two decades, PayPal stood as the touchstone for digital commerce. And with a long association with Elon Musk, the guy who tossed a Tesla into space, it seemed the appropriate means of managing our financial front end and integrating into our registration process. With the pomp of an executive in the 1980s, I adorned myself with the attitude: “You don’t get fired for buying IBM,” or PayPal in this case. Oopsy.

This integration balances on a three-part scale with trust in the second pan and regulatory compliance in the third pan. I’ll examine them in reverse order.

Mugshot

In my younger days, I occasionally feared wearing a cop car on my cheek. If this happened, I likely wore handcuffs on my wrists. Never happened, never even close, in case you wondered. These fears serve a purpose. For you, the viral mugshot that spikes your blood with fear serves as a deterrent.

Weekly, an IT firm’s name makes the news for a breach or mistake that costs people their security. That pop in the news triggers fears likened to handcuffs and a mug shot. My frustration with IT security breaches stems the patterns of victimization.

The IT firm that undergoes a security breach passes the victimization on to their customers. The bad actors steal from the corporation, in the most common narrative. The bad actors committed a crime. The corporation breached their duty. Yet, it is the consumer who feels robbed.

Normal human beings with credit card debt and housing expenses that are too high: these people suffer at the hands of corporate mistakes. Every year dozens of corporations make mistakes with data that harm people.

If I were to pontificate, I’d lament two matters.

First, justice skips the middleman in the credit card and identity theft crime. The middleman faces public shaming, and a possible fine. Justice rarely gets the thief. The victim stands numbly with financial identity tittering.

The second matter involves the architecture of the retail purchase process.

Let’s study the architecture of the retail purchase process. Competing forces confound the solution. The credit card once upon a time substituted for cash as a convenience. Carrying cash can be risky, though I do know a rich fellow in Puerto Rico who walked the streets with $500,000 in a backpack. His armed security detail abandoned him at the bank because it took so long to count the twenty-dollar bills. Bored or thinking they lost track of him, they drove back to his house without him.

A secure transaction involves multiple steps related to confirming identity and authorization. Are you really you? That defines authentication. This takes a lot of steps and effort – and can be fooled.

Not everyone wants a secure transaction. Anonymity is impossible with strict authentication. If you want a package in a plain-brown wrapper, you’ll need cash and a face-to-face transaction. With perfect security around a purchase, you’ve yielded all privacy.

Between these extremes sits the entire economy, from buying fuel at a pump to subscription-based software that supports your growing business.

Turn the knob too far one way, then procurement becomes cumbersome and secure. Turn the knob the other way, we enable identity and credit theft.

I should not tell either of the two following stories. They illustrate these challenges, and they are true.

I arrived in San Juan Puerto Rico on the first day of October 2017, about 10 days after Hurricane Maria cleared the island. I flew on one of the first commercial jets carrying passengers to San Juan. In first class with me was a famous actor from the island and his brother, a surgeon living in New York City. We came in low down the length of the north side of the island. My fellow travelers wept surveying the damage below us.

At work the next day, my chair rested at plastic folding table on the third floor of the Puerto Rico Convention Center. We were in the center of the room because we represented the governor and the government of Puerto Rico. Ricky, the then governor, had a private office in a meeting room nearby. As U.S. federal agencies poured in, security ticked up a bit. Everyone had to have a badge. The guards at the doors dressed in full battle kit with M-4 rifles and sidearms. The government of Puerto Rico was exceedingly slow to make badges – and at paying us; that’s a different story. The Puerto Rico badge making machine was chronically broken – or as I learned, without a knowledgeable operator.

I never got hassled. I wore the uniform-of-the-day: khaki military-style trousers called BDUs and a dark polo shirt with an embroidered logo. I wore the same or similar at Cisco System when I embedded with the military. I wore something very similar when in Iraq for a year – similar trousers from the same company.

I also wore my U.S. Army badge holder. I got it back in 2002 with I got my military ID. It is black nylon with a clear front for an ID. US Army logo show prominently. In this badge holder I put my U.S. passport card.

A U.S. Passport card is an optional credential for limited border crossings, yet very official looking. Let’s be clear, any U.S. Citizen can buy one for $40 from the U.S. State Department. While it accurately identifies me as me, it says nothing about whether I am authorized to be in the convention center.

The guards, most of whom worked for Hacienda (the PR financial agency), saw the red, white and blue, the UNITED STATES OF AMERICA with a very official photo. On through I went.

The Convention Center lacked any means of knowing good-guy from bad-guy, but they guarded it with weapons and flak jackets. I did, eventually, get a Puerto Rico government issued ID card authorizing my access to the facility.

By that time, FEMA started asserting itself. FEMA calls any facility that they share with a state, or territorial, government a “joint” facility. It’s a phony label. They tell their hosts what the rules are then demand their host follow them.

Now we all needed FEMA ID cards to gain access to the joint facility.

This is early 2018 and we’d move to a new location en masse. Getting a FEMA ID required just paperwork and more paperwork plus U.S. citizenship and a cleanish criminal record.

In the spring of 2018, I got yet another federal identification card, this one issued by the Department of Homeland Security and FEMA. The U.S. Department of Defense issued my last such card. Like the DOD card, it holds a digital memory chip. It identifies me as me on a computer system and when entering facilities. It holds my fingerprints. The card can be inserted into a reader to confirm the identification card has not be revoked.

And for me to use it, I need to call to mind the six-digit personal identification number. Long gone from my memory. As a non-federal person, we don’t use the ID card to log into computer systems.

The number faded from my memory the day they fingerprinted me.  Of course, I did not write it down. The only way available to me to fix this now involves me driving for hours to a major city then supplicating myself on a security office floor.

Ergo, useless! Fingerprints, security certificates, photograph, a brief digital biography, all useless because I can’t recall a six-digit number I gave to someone in a noisy security office in San Juan, Puerto Rico.

This episode echoes a problem from 2005 when training at Fort Hood in Texas. I took all sorts of classes while preparing for a one-year deployment to Iraq. Courses such as “advancing against direct fire”, “advancing against indirect fire”, and sessions on convoy protocols. I took quizzes on the difference between “concealment” and “cover”. Instructions included what to do when captured. No, I did not take the fancy course dealing with evasion from capture and interrogation, called SERE. I had a half-day or shorter thing. I forgot it all, immediately.

During the session, we were each videotaped and I picked my personal distress word. Forgot that too. If in trouble, my phrase indicated I was either: me, or fine, or in distress. All foolish. There I’ll be: bound in front of the enemy’s flag. My phrase informs the Army that I was either under duress, or not under duress. I am on an enemy video; the answer should be obvious. Washed out of my brain as quickly as the FEMA identification number.

Authenticating I am me; you are you – is an interesting challenge. A poor memory, or contempt of process, corrupts expensive government ID cards. I’ve illustrated how that fails. In this second example, I examine sincere effort to buy mobile phones in the aftermath of a catastrophic natural disaster.

The mobile phone bill following my first month in Puerto Rico was $2,500. My carrier informed me that I was roaming internationally.

We needed mobile phones that worked and were reasonably priced for operations in Puerto Rico. We lived in a hotel with the AT&T crew who rebuilt big chunks of that infrastructure. Sadly, no one could buy an AT&T phone on the island, or toothpaste. I arrived in San Juan the day after AT&T distributed free phones to many of my peers. Starting in March 2018, I tried to buy a handful of phones with my corporate American Express card. And failed.

Try number one: buy phones and ship them. Shipping reliability was so low, AT&T would not do that. Furthermore, I needed to be present to prove I was me.

Try number two: buy phones and have someone else pick them up. Three weeks of effort, and that failed. The person picking up the phone had to be me.

Try number three failed immediately. If a staff member buys phones, the accounts become attached to their social security number, their financial history, and requires AT&T to do a credit check on that staff member.

AT&T requires more paperwork and authentication than it takes to buy either a house or a car. I have bought both remotely with digital paper exchange, but not a mobile phone from AT&T.

Try number four: after flying to New England from San Juan, I walked into the first AT&T store I found. I bought five phones. Tired, grouchy, and a bit mean, I demonstrated a lack of patience and a fair dose of arrogance. No, don’t set them up. No, just give me the damn boxes and recognize that this is a simple transactional deal. I give you money, you give me a box with a phone in it and a service contract.

To my complete misery, we have two AT&T accounts. One for me personally. One for the corporation. AT&T can only authenticate me by texting crap to my phone. At my home office in rural Vermont, the AT&T phone does not work except via Wifi. I can’t do squat with AT&T. I can’t consolidate the accounts. If I want service, I must drive to Hatfield, Massachusetts, an hour away, to sit in a storefront. I can’t even log into their website because their authentication process is stricter than my technology and location will tolerate.

As a result, we will close our AT&T accounts and walk away from them (or run).

That’s the impact of tight authentication and strict rules during procurement. Too tight and it will result in the loss of business and complete frustration from customers. Too lose then customers face risks with theft.

It is difficult to get the security knob set to the right tick on the dial.

Let’s return to PayPal, the central player in this story.

Don’t Collect Their Data

The simplest solution to avoiding the proverbial mug shot involves never collecting data the bad guys want. John and I strive to create a system that meets good security practices, similar to those used by the military and financial service firms.

We acknowledge the risks and face the problem with humility. Who is best suited to safeguard the customer’s financial and personal data? Us or a firm dedicated to that process? Are John and I better than American Express, PayPal, or Visa? We’re not.

We are professionals in our realm and that includes securing data. But capturing, holding, managing, storing personal financial data sits in an adjacent specialty. We’ll not do that.

We won’t ever know your mother’s maiden name, nor your birthdate.

That means we depend on a trusted partner whom others will trust too.

PayPal’s logo appears ubiquitously on websites through the lands of internet commerce.

PayPal buys that liability from us while taking a financial slice of every transaction, nearly four percent.

Digital Connector

The architecture of an internet machine places the cogs, axles, and sprockets within the matrix of the internet. The concept of machine has abstracted as the materials, media, and methods of computing change, but it still a machine. We do not immediately recognize a mobile phone as a machine. That’s your fault, not the computer’s. A mobile phone remains a computer, at the core a CPU, memory, and a human interface. 

The terms “engine” and “machine” always obscured the complexity of technology – and yes, they once always included moving parts.

The architecture of internet-based software, cloud software, replaces cogs with digital connectors sharing data at light speed within the Center of the Internet (The Cloud). I witnessed an evolutionary process. Modern software now also employs the internet as a backbone to exchange data.

Our machine, Podcast-Flow, presents itself as a node on the global network, connected.

To link our software to PayPal, we write a digital connector. PayPal provides details, definitions, and examples for us. They also provide a sandbox to play with. The early technical steps require we inventory the tasks our machine does – what buttons we need to put on this internet machine of ours.

Let’s go through that for Podcast-Flow…

We sell subscriptions. Therefore, we need to exchange subscription data. We’ll need to get some details that confirm payment, customer’s name, and an email address. We’ll need to provide people the ability to cancel a subscription. Each exchange of data requires us to write code.

We write in Oracle’s PL/SQL. The data exchange is made via the hypertext transfer protocol (HTTP). The data travels in the JSON format – JavaScript Object Notation – squiggle brackets, text, colons, commas, and a few square brackets.

Our technical team names the programs descriptively such as: “subscription get”, and “product get”. The language of moving data to and fro became get, push, post, patch, and delete. We push data to the other side. We get data from them. When we push data, we send a payload formatted in the proscribed format. Our program that gets subscription data is 50 lines long, less than 2000 characters. A fast typist is done in 30 minutes. A good programmer, likely done in 10 minutes or less because she would copy then paste from something similar.

Not That Simple

The team dug into the documentation from PayPal working through the primary steps. We quickly discovered that their online documentation contained errors and inconsistency. We spent hours and days reconciling their documentation with code that worked. The process resulted in frustration and anger. Additionally, working through their errors cost us money. We paid wages for our staff wasting time un-messing PayPal stuff.

After days and weeks of frustration, we identified a big black hole in the process. I failed, we failed to see that PayPal does not offer ability to list all subscriptions. The only way to get subscription data is to give PayPal the subscription ID that PayPal assigns. Thereby creating a Catch-22 situation. We can’t get subscription data, including the subscription ID without the subscription ID.

The only way for us to get the subscription ID requires that we use their tiny, old-looking payment window.

When we use their ugly, tiny, old-looking payment window, we can offer no variation to the pricing. We cannot easily do bundles or add-ons or discounts or coupons. At the end of the process, PayPal flashes a hidden message containing the subscription ID for us to grab. We must fetch it then or we sink into muddy mess of manual research.

The second option then involves us capturing the name, address, credit card information, expiry date, etc. on our system. We format the data before sending to PayPal.

Oops, if we collect it, we own the liability for safeguarding those data. Not part of the deal, PayPal. We pay you as much as 4% of every transaction for the management of financial compliance but on step one, we violate the rules. Not going to happen, PayPal. No thank you please.

The process unraveled in December of 2019 when we learned from our accounting staff that we must collect sales tax in the United States. That broke PayPal.

In June of 2018, the United States Supreme Court issued its ruling in “South Dakota v. Wayfair”. This changed the digital commerce process forever. 18 months later, PayPal remained non-compliant.

There slips PayPal into history. Bye, Bye, PayPal. You’re now a faded sticker in a store window.

We need a partner who aids with authentication of customer, securely executing the financial transaction, while giving us the ability to focus on the complexities of our business.

Time to find a new solution and write an entirely new digital connector.

04 – Plans

by

Listen to Podcast on Your Favorite Service

The Top Six Secrets in this Chapter:

Check the brand name in other languages

Maybe naming a car no va as Chevy did is a problem. 

Check misspellings of the name

Just how easy is it for someone to troll your brand

Break Name in Segments

“Top or Not” reads “to porn ot” – Just give it a try.

Search and Search again

What does that name mean to people? Why might Maddoff’s Mattresses fail at providing a night’s sleep.

Searh & Execute Domain Name

There are evil-doers lurking on the web. Sometimes when you search a great name for Domain Services, it gets bought while you delay.

Buy Domain Name with varients

Having a dot-co and dot-com can be useful. Also protecting your brand from trolls is good too.

Transcript

By July 2019, we drafted perfect plans. We’ll get to market something quick. We will hit 75,000 subscribers within six months. We’ll beat all related records.

Of course, we were wrong. Our plans for marketing and technology fizzled by August. By September we exuded confidence as we found new paths forward. One element of our plan remained pretty solid: the product name.

With a product name, a marketing plan, and a technical plan, we need a business structure.

Then it goes, grows, and fumbles on from there…

The original marketing plan involve getting pulled along by a powerhouse in the podcasting marketspace. Some super-big, super-important person – that I had never ever heard off. A name mentioned with reference. We had a backup super-important person, another global influencer. And even a backup to the backup. Regardless of the charismatic influencer, the plan involved splitting revenue with that human being for their market.

This is why I was being told to use pastel versions of pink and green – which I entirely hated. My business partner, John, hated the palette too.  I say: those colors are exclusionary. A huge pile of people looking at anything with those colors would say: That’s just not for me while walking. In my youth, I knew of a few men who would wear such colors, but only at the country club and golf course.

By September, thankfully we abandoned pink and green. Kelly worked towards new plans.

Together, we walked the roads around our place in Vermont re-inventorying our assets and direction. By the time, we took this walk, the technical team hit our first major failure and set back.

What was a few quick thoughts of: take an existing product, paint it pink-n-green, selling to a enthusiastic market proved to be a bit optimistic reminding us that a product launch, or a business launch is always more complicated, has more setbacks, and requires more work than one envisions in the early hours.

Our technical failure, told in the next chapter, related to our need to process payments.

Data security stands as a global crisis and problem. Data firms love to collect it. And thieves love to collect it. If you don’t collect the types of data thieves put a high value on, then you’ve reduced your risk somewhat.

John and I host systems that manage a lot of money on behalf of governments. BUT! That money is not cash. I can not be spent. We track and record activities related to the money. And we tell our clients that we do not accept the storage of personal identification information, also called PII. Storing tax identification numbers, personal addresses, dates of birth and the like involves a heightened level of security. While we meet and exceed these standards, we also do not like the risks. Our system does not require these data, so why open ourselves to this expose.

Our podcasting project with an engine or tool that we will sell retail means that we must find a means of accepting payments and working very closely with PII. Holding PII and working in a retail space increase risks significantly.

John and I run a firm that is rather obscure and little visibility. We sell to governments and basically nobody else. We don’t need to advertise or do much that is flashy.

The podcast project will run ads, make a murmur that may be heard around the globe. Notoriety cuts both ways. With revenue and visibility may also mean you are a lovely succulent target for thieves.

Working with credit cards and banking data requires even more security that storing PII. PII is the sort of thing one can find in a telephone book, on voter registrations, records of donations to political parties. While sensitive, people often publish it anyway. Credit cards and financial data ticks ups the concern.

The Payment Card Industry Data Security Standard is a globally accepted means of increased controls around cardholder data and reduce credit card fraud. Any firm that accepts credits must work within the PCI (Payment Card Industry) standards. The absolute best means of complying with these standards is by not collecting or managing data related to cardholder data.

Ironic?

In order to get paid by any retail customer on the internet, you must accept credit cards and on-line credit processes. When you do, you increase your risk of exposure and step into a strict regulatory environment. Risk exposure and financial regulations cost money. Adherence is also good. This is not the moment a business owner spews: “Regulations are evil.”

Following the regulations protects people, their credit, and all sort of good things.

John, an expert in cybersecurity, firmly stated: “We are not touching credit cards”. I offered no argument.

Therefore, we need a vendor to manage credit card purchases for us at that wire-speed we expect in the Center of the Internet. In other words, the moment a customer pays, we setup accounts, email a welcome statement, and do all of the right things. And do it without delays.

Done right and well, we have minimal compliance and provide proper safeguards to our customers.

The master plan has a few tasks:

  • Develop a product name;
  • A business plan and a business structure;
  • Find a vendor slash partner to managed credit cards and payments;
  • Design a means of registering a customer without any effort by our staff, or with added delays;
  • Re-design with application with a new color scheme (yay!);
  • Design a new marketing plan;
  • Studying the software for improvements (why not, we’re taking out a paint brush to recolor it anyway).

Product Branding

The Apple Computer Company formed in 1976. The internet protocol was two years old.  The barest of skeleton exists for the ARPANet, the predecessor to the internet which was then 10 years old. And 1976 was six years prior to the release of the IBM PC.

Apple Records is a record label founded by the Beatles in 1968.

In the 2000s, the two companies named apple, each with an apple profile as a logo collided and faced conflicts with on-line music services.

In 1962, the Chevrolet automobile company introduced the Nova as a small automobile. The name stuck around for two decades. In Latin, nova means new. In Spanish ”no va”, means “not going”. Few people want a car that does not go. I am more a vamanos sort of person .

IBM introduced a product named the Personal Computer which everyone abbreviated to PC. People got particular enough about their brand loyalty that if you asked a user of an Apple computer to go to their personal computer, meaning the computer that they personally own, they would inform you that they do not have a personal computer.

IBM effectively took two common words and branded them together. Owners of Apple products eschewed any sort of personal computer. They owned an Apple.

Thus, endeth my treatise on branding.

Branding is important. It is global. And the context of a brand name changes with decades.

When branding via the internet, there added challenges. The name you want must be available for a price that is reasonable and must be safe. For a while in the 1990s, the domain “Whitehouse.com” carried the unsuspected visitor to a porn site.

My checklist for branding a product or company involve the following:

  • Check the name in other languages (think: no va)
  • Check the misspelling of the name
  • Break the name into funny segments: “top or not” also reads as “to porn ot”. Avoid that bit of awkwardness in your life – unless you are serving porn, then charlie-mike (continue movement) my friend!
  • Search the name aggressively on internet search tools – news articles around the globe; anything that might show why “maddoff’s mattresses” might be result some surprises in the marketspace.
  • Search the domain name with your favorite trusted vendor for such things – and be ready to execute. When you find a name, buy it. There are unscrupulous people and unscrupulous vendors who when finding interest in a name, buy it while you ponder. Better to buy and let the name expire or go in a year than to lose the perfect name because you took two days to think.
  • Buy the domain name with some popular variants.

We use a “dot co” version for a Google account. We used a “dot com” version for Microsoft email and accounts. Also be fair – you have about 8 billion neighbors living with you on this blue marble. Maybe you are that person just buying domains to hold them hostage as a business model. Good for you. Sleep well. I’ll sleep a bit better by being a bit fairer.

Our team bought “podcast-flow.com” within hours of having the idea. By mid-July 2019, we bought related domains: podcastflow.info and podcastflow.net

In early October 2019, Kelly envisioned selling a course about planning, production, promotion, and profiting from podcasts. The first name was Podcast with Purpose. I immediately drew a cartoon image of a porpoise at a microphone wearing a headset. From then on, John and I insisted the course was named “Podcast with a Porpoise”. Within days, Kelly found a podcast and other internet material with similar names – several people using variants of that name.

We backed away from the name “Podcast with Purpose” (or Porpoise).

 

Podcasting with Porpoise
Podcast with Porpoise

Our process remained consistent as we expanded the business plan and marketing plan. Search, check, review in multiple languages, chunk up the letters oddly, then execute blindingly fast.

One of our course names is “Hack Your Podcast”. John and I still prefer to call this: “Hacky our Podcast”. It is the same spelling. And it annoys Kelly to our delight.

Business Venture

John and I owned a company together. Kelly does her own thing. Therefore, we needed a new business venture to unify the effort. We registered Podcast-Flow LLC in Vermont. I wrote our agreement on an email resulting in a more formal version of the napkin agreement or handwritten agreement one would find on lined notepaper. We used no lawyers and accepted little risk.

We own this. You own that. We’re joining forces as Podcast Flow LLC for this purpose.

In time, we formalized and improved. We accepted the small risks associated with an informal email. We did get a lawyer involved, and a CPA firm. And all of that messiness. But not in the first months.

Credit Cards and PayPal

In the next chapter I explore our efforts and failures with PayPal. I alone thought PayPal belong in our plan. Within months, I retreated with frustration. We were defeated by PayPal. There slips PayPal into history. Bye, Bye, PayPal. You’re now a faded sticker in a store window.

Semper Gumby

The master plan remains as flexible as my plastic friend Gumby. Within six months of our simple idea to re-use an existing product, we were building a new product. Actually, two. And we blasted through two more marketing plans. And we recognized we needed more on-line partners. And we recognized that our help-desk tools and software were insufficient for the job ahead.

Oh, and we need to find a means of collecting sales tax in the United States.

The complexity manifested day by day in front of us.

Our failure to recognize the growing scope, well, rather our willingness to expand our own scope resulted in delays and added work and added costs. We are a tiny company with few financial resources investing hundreds of thousands of dollars in research and development. We pursued the investment with an understanding of a rapid payback with a brilliant and large launch of a product into a welcoming global market of podcasters.

By December 2019, we all started seeing news of a new virus in Asia. By January, we knew it was in the US. An old expression from the army is that “no battle plan survives the first bullet”. The corollary to this adage: “no business plan survives a global pandemic”.

Another battlefield expression is: “Semper Gumby” – always flexible.

Gumby
Semper Gumby

A Newer Marketing Plan

Marketing Plan version 2.0 or was it 3.0? We recognized, everyone recognizes, people do not buy software. Frankly, a lot of people hate software. In a prior chapter, I stated that software, apps, applications, and websites are all the same thing. To some, apps are sexy and cool. Software is stodgy and grey.

Regardless, Kelly started designing courses for podcasters to resolve specific issues, share trick and techniques, and to also support our app. This approach cradles our podcaster customers in the warmth nurturing happiness that they may want.

Unknown to me was that each version of the marketing plan required additional technical effort, additional software development, and additional costs.

Harrumph!

03 – The Machine

by

Or 5 secrets to a product plan

Listen on your favorite service

share

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Transcript

PodcastFlow is an internet machine. PodcastFlow completes a series of tasks, has some automation, required designing and building, and it uses energy.

What is a Machine?

Once upon a time, we could clearly discuss the difference between computer hardware and computer software. Together, they create a machine that does something.

During the recent two decades, all of what I knew about hardware and software disappeared. You were likely taught: Hardware is that stuff you can touch. Software is stuff someone writes. For all of you that held on to those definitions, it just isn’t true anymore.

Give a tug on your helmet strap, tighten your bootlaces, and take this leap with me. Since around the year 2000, the entirety of a computer can be managed as software. That chunk of iron and plastic you have as a laptop, desktop, or even as a mobile phone can or is actually entirely software. Yes, your laptop computer is still hardware. You can touch it. You can toss it out of a window and smash it. That physical bit of stuff is actually and still hardware.

But, somewhere in a massive room in Ashburn Virginia and other places on this globe, people like me run computer that are entirely software. The server itself – all of it’s bits: the disk drives, the internet connection – all of that is software. We can make a copy of it. We can move it. We can clone it. We can instantly make it run faster with more memory and more processors. It is, in the parlance, a virtual computer.

The servers upon which we run our Oracle software, the servers upon which we write in the language PL/SQL are virtual. I carry a mental picture of a flat black box mounted on a 19-inch rack in a computer server room. I haven’t seen one in fifteen years, so I cling to that image.

That image that is wrong.

A machine does something, maybe something useful. I have given up differentiating the difference between an engine and a machine and hardware and software. No solid lines of demarcation exist. Each are simply metaphors. Sure, I can – sometimes – point to the engine on a jet or the engine in an automobile. Probably because that is where the noise comes from and I might just see a cog, or something move.

Maybe one would expect that an engine or a machine is the sort of thing you can whack with a hammer or find a bolt to tighten with a spanner. That definition is a legacy from the industrial revolution.

An engine is a thing that does something. Let’s improve this definition: How about an engine is a thing that does something to something with a bit of automation in it? Or maybe a machine is a thing that does something, has some automation and it either uses or produces energy.

Someone designed and built a machine to do something.

PodcastFlow is a machine that helps people plan, promote, produce, and profit from podcasts.

Our machine sits in the Center of the Internet – The Cloud. It uses cloud computing and cloud storage. It is hardware and software. It has digital data connectors to several vendors. The machine is a bunch of different parts that work together. When you stand on the outside of that machine, it just looks like magic.

Wanna know what else I know about machines?

People do not buy machines. People buy tools, but only when they understand their value and importance.

I am fascinated by tools and machines from hand planes to airplanes. That’s me and that can highlight a significant flaw when managing a business. 

The 5th of June 2019

In Chapter 1, I introduced you to Kelly Dodge who called me on the 5th of June 2019 with an idea. As a software developer, listening to an idea for an app is as common as a medical doctor having to listen to some rando sequence of symptoms when not at work.

“Oh, you’re a doctor. My clavicular sphincter resonates whenever I eat fried broccoli then stand near a green Volvo.” Seriously, stop reading the internet looking for medical assistance.

Clearly swiping left and swiping right caught on. That thumbs-up thing became popular. Also, I have heard I can learn some dance moves on other apps.

Kelly got my attention with a good idea. Let’s help podcasters plan and produce a podcast.

Kelly knew what to say to a business owner.

First, she described a suite of services or tools that podcasters would value. Nice start, especially when talking with a tool smith. Interesting tools are cool. I build tools.

Kelly did not know we had a related tool that had no market and no customers.

Second, Kelly described the market potential for a business venture. She knew how many podcasters there were; the growth rate of that market; the potential for revenue in that market.

Third, Kelly identified what the market was missing. She saw a niche. A niche is important for a new product. How do you find your customers? And how does your customer find your product? You need to differentiate your widget from all other widgets.

Fourth, she outlined how the business venture would be valuated for potential sale to another firm. Kelly put the end-in-mind at the outset of the project. That’s a trick many of us learned from a guy telling us about the seven habits of successful people.

Fifth, she stated that she, Doctor Doctor Dodge, would be invest and participate in the venture. She accepted marketing and product design as her role and key contribution.

Kelly and I have collaborated since 2010 on projects. Normally, I work for her as a ghost writer. I know her well enough to understand her entire presentation was off-the-cuff. At 24 she was the V.P. of a company with 5,000 people and tops in its industry. She was later a business development executive and strategic planner at B.A.E. – a global defense, security, and aerospace company.

Off-the-cuff, Kelly hit five key elements of a product plan. Given her background, that she does this is not a surprise. It is a necessary discipline for business owners and software developers thinking of that killer app.

Throughout my career, I emphasized my skills designing and building tools. Let’s go build a tool and we’ll find a market is a strategy I have engaged in repeatedly. Which is how my firm owned a project management application in the spring of 2019 with no customers.

Task number one – identify a market for the machine you want to build. I did not do that with my project management tool. Our customers in Puerto Rico wanted a means of coordinating the complex activities of their disaster recovery staff. My response: I’ll build a classic project management tool that does Gantt charts, makes pretty calendars, emails people tasks, keeps track of meeting notes, and stores project documents. There is a disconnect. This tool smith built the tool I thought I’d like.

The center of the thought process can not be “me” but “market” or “customer”. That’s a fail. With Podcast Flow, we made the commitment to serve the market on their terms. Thank you, Kelly.

Task number two – understand the market potential before spending money. Ventures, even non-profits, need to balance the financial books. The bills must be paid, and payroll must be met. Pulling out a tape measure while striving to measure the potential revenue and potential size of the market must be a factor in deciding in going forward.

Task number three – seeing the niche, recognizing the needs of people. Better and different may not be sufficient factors to get people buying your engine over the engine of another.

Podcasting, like so many concepts on the internet, started because one or more of my kind said: I can do this. Podcasting is a kludgy mess of borrowed technology. Those who want to write, produce, and profit from a podcast must engage in numerous disciplines. Entirely analogous to being an entrepreneur – writing, audio engineering, geeky-web stuff, social media, communicating with your listeners, and finding sponsorship. That’s a minimum of six skillset. Not a barrier, just a challenge. Even opening the simplest of businesses requires: bookkeeping, attracting and retaining customers, doing that thing that is your business, dealing with vendors.

Apple does a fine job of hosting podcasts and so do another dozen companies. Looking into a market space to see what is missing, then knowing you can meet that need – that is a gift.

PodcastFlow is not technology tossed into a marketplace full of technology. That results in failure. When talking about opening a restaurant, or a retail shop, or an on-line market stall, or personal services firm; knowing how you will differentiate yourself is key.

Task number four – always know where the exits are. There are eight emergency exits on this plane – we know the song and the dance that goes with that routine. Each business plan, or product plan need a minimum of two exits. What to do when you recognize failure? And what to do when you recognize success? Of course, of course, we never plan for failure, blah blah blah. Entirely not true. I have been a volunteer firefighter since I was about 18 years old. Off and on during my life, I have worked as an EMT then paramedic. And I spent a year in Iraq as a civilian member of the U.S. Army’s Fourth Infantry Division. Guess what, in every case, I was trained to plan for failure and have plans for when things go horribly wrong.

Planning for failure and planning for disasters does not make them come true. And it does not create a defeatist attitude. These plans often demonstrate depth and resiliency.

Planning for success is often just as difficult. Most of us that start a business think about paying the monthly bills, eating regularly, and taking care of those around us. When you deliberately plan the exit strategy for success, then you’ll necessarily push the event horizon. One might just recognize that retirement and family and activities other than work could, just maybe, take tick higher in priority.

Our exit strategy for Podcast Flow LLC is simple. When the annual projected revenue meets x value, the company will be valued at Y. At Y value, we will sell and do something else.

And task five – Acknowledging that marketing a new product requires lead time, cash, labor, thinking, and commitment. Marketing and product development must interact, collaborate, and share common goals and commitments. If you are that special, amazing person that can do both, celebrate that.

I am a tool smith. I have long known that. I rely on others to support me in the marketing roles. I must work within a team to bring the balances needed for success. 

A sixth rule exists too. One must be flexible. Semper Gumby baby.

Gumby
Semper Gumby

The 6th of June – D-Day

Within a day, Kelly and I roughly described the needs for a product. It had no name. It had two elements. One: We had complex suite of unused software that needed a market. Two: We had a pretty good sense of the market.

Podcasting is a repetitious activity. Atul Gawande wrote a terrific book called “The Checklist Manifesto” informing the reader about the value of the lovely and humble checklist. Atul Gawande is a surgeon writing a book, therefore included the surgical theatre in his stories. I read this book while training as a paramedic. Shortly after reading this book, I stood as the junior-most person in attendance at a surgery. The head surgeon and chief nurse in the room stepped through a practiced checklist, as if they too read “The Checklist Manifesto”. In a full clear voice, a young doctor-in-training read the patients allergies. A check in a box. We called out our names and our reason for being in the room. I was there to intubate the patient. I had interviewed the patient. I had gotten consent from the patient. I would insert the plastic breathing tube, test it and walk out. One of the statements on the checklist was: Everyone is equal when seeing a problem. When the first drugs were given, I stood at the head of the patient. A young doctor taped the patient’s eyes shut. I said: “Patient allergies included tape adhesive”.

Damn if the entire room didn’t listen to me. The checklist worked.

The planning, production, promotion and even profiting from a podcast involves a series of detailed checklists. Some of the tasks are things we love like writing. I love to write and tell stories with words. Some of the tasks are things we may hate doing. For some that may be writing. I like to write. I hate to self-promote. I hate to tweet.

The gift of a checklist comes from the consistency. A surgeon with decades of experience listened to a paramedic who remember that sticky tape will cause an allergic reaction on the patient’s eyes. “Gee whiz doc, my knee feels good, but I can’t open my eyes.”

The checklist also facilitates teamwork, coordination, and collaboration.

The humble checklist permits us to refine a process then improve it. I know why a surgical team reads a patient’s allergies out loud to the entire team. Let’s not forget that step next time. Somebody made that mistake before, right?

Kelly listened to a podcast hosted by a team of people who wrote a series of checklists for podcasters. Follow these steps and you’ll be more successful with your podcast. Nice. Perfect.

Spreadsheets are terrible at scheduling on a calendar. They are terrible for tracking complex data like a database does. Spreadsheets rather suck at sharing data. So many problems.  

I get it though. Spreadsheets are easy and accessible.

Is managing a series of checklists really what an internet machine does? Sure, why not?

What gifts does the internet have to offer a podcaster, or anyone involved in repetitive processes? The internet connects things. Checklists connect with calendars. Calendars connect with email. Email connects people. Checklists now connect with people.

The internet stores things. So instead of just ticking that a task is done, put the data with it. Put the script next to the tick-mark for the script. Show the keywords. Show the episode plan.

Show and tell and do and share. Now you are on the internet. A spreadsheet can’t show and tell and do and share simultaneously.

My team had built a classic looking and classically functioning project management software application. Rather stodgy looking too. It can have an infinite number of projects and tasks. It tracks dollars and time. It tracks the completion of tasks. It does all of the things that Microsoft Project does except it does it in an Oracle data and runs on a web browser. And because it is on the internet, it can email people. It can send information to people’s calendars. People, when the login can see what they are supposed to see, and they cannot see what they should not see. That’s just modern software. There are numerous competitors and some of their products are pretty good. I believe I saw a niche by blending it with our grants management software. Track the dollars, documents, and data related to grants. Then also track grant funded projects: who is doing what with what due dates. That sort of thing.

This big robust tool sat on the proverbial shelf when Kelly describe the need for a checklist.

Oh, isn’t a project management tool really just a big complex checklist tool? They are kind of the same.

Our team could nearly immediately offer Kelly an expanded view of the process.

Instead of calling anything a project, we call it a show.

Instead of sub-projects, we call them episodes.

Instead of hand-keying tasks for each episodes, use standardized and tested checklists. Let’s replicate successes and avoid known failures.

So now tasks are checklists and checklists are tasks. But these tasks carrying the intelligence of other people’s experiences and successes. They are not just tasks or checklists, they become workflows. When people collaborate, discuss, share, and improve on workflows everyone does better.

Podcasters are not competing for an audience with other podcasters. There are more listeners than there is podcast material. The audience for podcasts has unmet needs.

This podcast, my podcast called “The Soul of an Internet Machine” about business ventures, entrepreneurship, software development, and technology will not steal anyone else’s audience. An audience will enjoy this show and that show. Podcasters can collaborate and share without competing.

This internet machine that behaves a bit like a project management tool to help people with repetitive tasks in podcasting, also brings the value of people in community and shared ideas.

From this first day, Kelly and I included members of my team. We added and rejected ways of expanding this product.

We knew that we needed to be as hip and cool as other internet based services: we had to permit people to express interest, register, buy, and gain access to the software without any behind-the-scenes human effort. We were not going to pay for technical support staff to work around the clock to help setup customer accounts.

We had to entirely automate the buy, registration, and setup process.

Kelly, of course, had very simple notions of this. The technical team kept hearing, its just as easy as setting up an on-line market space.

Sadly, no.  

Our machine had to process credit cards and register users automatically – which is not something our firm had previously done. We’ve worked on big database projects managing billions of dollars and 400,000 documents for governments. Not the sort of thing a person-off-the-street buys access too.

Our machine needs to be easy and enjoyable to use – rather as intuitive to use as a knife or an axe. An axe does not have a sign that says: this is the handle; and this is the sharp part. Many of us have used an axe as a hammer. And some of us have used a knife to whack things too. But that is off topic, but only sort of. Software developer also think about, what will the users of this tool do with it?

Our machine has to email people and track stuff in a podcast-y way. A podcaster, even a new podcaster need to look at the machine and see what to do. Software is never as elegant as an axe, but it is a nice idle image: hold here, hit with sharp part.

Our machine may just need to store data such as scripts and draft audio or meeting notes or whatever else we can envision, or a podcaster can envision.

Our machine has to be useful while helping podcasters achieve the successes they desire. Some podcasters want revenue. Some want to support a cause. Each has a voice that deserved to be heard.

That becomes our commitment. Let people be heard.

How we build a machine that aid people in being heard will come in the chapters and stories in these series. I release new chapters each Wednesday at 6am Greenwich Mean Time or UTC.

02 – The Cloud

by

Listen on your favorite service

share

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email

Transcript

The Cloud does not have a birthday. The internet does. The web browser and HTML do. The internet protocol (IP) does. The Cloud not so much.

During our lunch walk up and over the near hill, I asked our Rachel: What is the Cloud?

Rachel, at 36 years of age, holds a master’s degree from Rutgers.

Now I understand the starting point.

How come poor cloud has no birthday? We, we IT people, took a cheap short cut when drawing picture of networks in buildings or campuses. We made boxes and connected them with lines that look nothing like Google Maps, but something  like a silly drawing with square-edged boxes and very straight lines. This being the stick-people equivalent to the drawing other types of engineers make. When we finished, or started, our drawing with connected to The Cloud. We dropped a picture of a cloud at the edge of the paper. I was doing this as far back as 1995.

IT people defined “that other place” or “that faraway place” or “the rest of the world” with one simple icon for a cloud. There is here and there is there. When we drew a picture of “there” it was a cloud.

That icon never represented anything but a nebulous, amorphic, impossible to touch entity.  The Cloud shows in computer science and marketing literature for decades. Long before 1989 when Tim Berners-Lee proposed hypertext and the World Wide Web. The first website was published on the 20th of December 1990. The cloud icon was used even before the Internet Protocol was vaguely defined in 1974. The forerunner to the internet was called ARPANet. It can claim 1966 as its birth year.

Our walk through the autumnal forest took place on a cloudless day. The sky today is a stunning blue – postcard blue. As Rachel explained The Cloud to me, she pointed sky-ward.

Netflix comes from The Cloud. And my iPhone, she says, stores pictures on The Cloud.

And when things go wrong between phone and cloud, you just wait.

It was about then, that her phone got the daily batch of text messages. There is a spot on top of that hill where Rachel gets just enough cellular coverage to fetch text messages. We pause while she scans them, then walk on. She does ask as we start down the side of the hill, how come all of these don’t come when I am on Wi-Fi in the house. I shrugged. “That’s just Apple being Apple. They don’t play well with others.”

Those text messages queued up in The Cloud waiting and hoping that Rachel would appear at the top of our hill.

And then there are those damned blue spinnies when watching TV of an evening.

Oh, and when I push one of my podcast episodes to The Cloud, I entirely kill my network. My music stops and I may as well pace the yard.

This is the starting point. I will strive towards a better and more complete definition for The Cloud – and a definition that will meet the rigors of my technical peers while sating the intellectual curiosity of others. The Cloud remains amorphic.

Definition one: The Cloud is some remote place that stores data such as pictures, movies, words, numbers, and files. A good foundation.

If everyone stored and retrieve data from The Cloud with equal ease and equal speed, then The Cloud would be at the center of the Internet. Normally, if your connection speeds are slower or non-existent, it is because of where you are and where you live and where you are standing. In 2020, I would have preferred that our house was on top of the hill where the cellular reception is. Instead is it lower down where the power lines are. That is a trade-off.

Listen team, the universe is infinitely large and growing yet somehow has no edges. I learned that in school. I grew up with an astrophysicist as a dear and close friend of the family. While tennis was a more common destination for a summer outing, the Harvard Smithsonian Center for Astrophysics was popular with our clade. My first class in astrophysics was in eight-grade, in 1977. And due to the odd form of our household, blackholes and x-ray telescopes got discussed at the dinner table. That was also my very last class in astrophysics, too.

The internet is also infinitely large and growing yet somehow has no edges. We’re launching dozens of satellites into the sky to expand the internet there. I am ok saying that there is a Center of the Internet.

What is the Cloud

It is exactly as true (or not true) as saying there is a center to the Universe.

Ask the mathematician, if nearly every home, office, and mobile phone gets the data they need is nearly the same time, then each home, office, and mobile phone is equidistant from the center of the internet.

All humans, and their dogs, are roughly 6,371 kilometers from the same point. Every one of us, and our dogs, are equidistant from the same place. That place is the center of the earth.

So, if everyone of us can ping the center of the internet in 50 milliseconds, then bingo, then there we are a brief 50 milliseconds distant from the Center of the Internet.

We want websites to load quickly. Blue spinny-circles disturbs our movie watching experience.

Years ago, the internet had no center. Oh, I am not going to get all Genesis on you, here, just practical.

Commerce was lured into the Center of the Internet starting in the mid-2000s. There are millions and billions of reasons for this, primarily the millions and billions one can earn.

Inside Podcast-Flow, we entirely depend on being at the Center of the Internet. You find us via a website which sends you to a website extoling the amazing and important virtues of Podcast-Flow or one of our courses. Forgive the hint of snark related to the language and tricks of the marketeers (and my friend Kelly). From this website, we send you to a buy page to buy our product and enter your credit card. Within a half-second, 500 milliseconds, your credit card is processed and our system sends your information to firm that helps us identify users and track what permissions they have. Within milliseconds, we establish an account for you. At that same instant, we establish your data profile in our Oracle database.

There are four entirely separate firms simultaneously engaged in the buying process. We expect each of these firms to respond to us via the internet within milliseconds.

This works because we are all located together at the Center of the Internet. The speed of our connections and the size of the circuits connecting the firms are massive. These systems behave as if they are in the same building.

There is zero tolerance for blue-spinnies here in the Center of the Internet.

A decade ago, when I designed and wrote the first version of Tempest-GEMS, a grant management system. I wrote in a language that I first learned in the mid-1980s. I used a database system developed in the 1970s. I used techniques to optimize speed learned over decades of experience with the internet and software development. Of course, the application was fast and gorgeous on people’s browsers because of Oracle APEX.

In time, we wrote a link to FEMA, the Federal Emergency Management Agency. We pulled, we do pull, grant data from FEMA. We do it once per day. The data we get is about three days old. It is good enough.

This is how we all worked for decades. The internet was never really fast enough, nor reliable enough to expect real-time data. We’d all share data when we could and as best as we could. We called it best-effort. We had to engineer tolerance for failures and slow data rates.

The first people to convene at the Center of the Internet were traders in stocks and bonds. They can make millions by being milliseconds ahead of a trend. Those of us working with grant data, auto parts, shipping waybills, even medical data – we never expected services measured in milliseconds.

When working with international shipping of freight during the mid-1990s, as long as the data about the freight arrived before the airplanes carrying the goods, we were doing pretty well. When I deployed a telemedicine application in rural Alaska for the Indian Health Service in the late-1990s, one had time to pour a warm cup of Earl Grey between asking for an X-Ray image and it appearing on the screen.

We moved large data from one edge of the internet to another edge of the internet. We understood that it took time for this movement to happen. The internet was a series of tubes. This is what Ted Stevens, senator representing Alaska. He said that in 2006. Coincidently, Uncle Ted was the individual solely responsible for all of my projects in Alaska, including the telemedicine system we deployed in 1998 and 1999. Our projects had to ask Uncle Ted for more money to build these tubes and pipe into the far reaches of Alaska.

To politicians and medical staff, we had to explain light speed, distance, and all of the challenges of the internet. The x-ray image started in Anchorage, then went to a satellite, then down then across town, then to a computer. There are very serious challenges moving big data from one edge of the internet to another edge of the internet. It takes real time, time you could measure in seconds.

Podcast-Flow cannot wait two seconds for a credit card to process. That would cause your browser spin slowly. And if each task of setting up an account took one, two, or three seconds, that might mean a ten second delay. Ten seconds is the time it takes me to read a short paragraph. Ten seconds is enough time for you to notice a significant delay on your browser.

When we processed a credit card from Puerto Rico yesterday, it took 523 milliseconds about the same amount of time it takes for me to say the word: “One”. We won’t set up your account with PodcastFlow until we’ve gotten confirmation that you have paid. As we setup your account, we send the data to Okta to set up your identity account there. That should take a few milliseconds. We want your entire account setup then trigger your welcome emails within a second. Your first email should arrive at about the same time as the receipt appears on the website.

In 2013 and 2014 when designing Tempest-GEMS, I build a machine that runs on the internet. It uses the internet as if it were a “series of tubes”. You would work via a browser on your desktop or laptop. And the data got stored in our database. This architecture is so classic, I recognize that its roots go back to the beginning of computing. Over here is a terminal with you working. And over here is the database. There you go. Done.

With the internet, we stretched the distance between terminal and database. With time, the terminals became more sophisticated, more colorful, and bigger. That’s just industrial evolution at work.

In 2020, the architecture of our software, PodcastFlow, expands beyond our own computers, beyond our own firm. We are pushing and pulling data from other firms with perfect reliability, with amazing speed, and with no practical limitation on the size of the data.

Instead of building a machine that runs via the internet, that treats the internet as a series of tubes, we built a machine that runs within the core of the internet itself. We are not longer just passing data between a server “in the sky” as Rachel called it, and your workspace. No, the architecture of our machine, our software, 100% depends on all of our partner services operating with the same speed and efficiency that we do.

In the old days – such as a decade ago – if a system had a 100% reliance on some data, you fetched it and stored it. They were them. We were us.

Today, in a fully-integrated internet machine their tools are our tools; their data are our data. The user experiences a fully integrated internet machine that operates smoothly. The software developer building these machines will invest significant time on sharing data efficiently.

It is as if the backbone or skeleton of software blends with into internet. Think: Borg, or Cyborg, or bionics.

I once wrote software that worked handsomely within a boring little Oracle database. I owned the Oracle. I owned the computer server that the Oracle ran on. Today, I write software that trusts and relies on the internet just as if I owned the internet.

I don’t own the internet, we pay for this experience. We pay to put our technology right there in the Center of the Internet. When I reach to the bank to process a credit card, I get a response 100% of the time and done within the blink of a human eye. That bank is not somewhere else. It is at my fingertip, right now, all the time. I write my own software to manage the banking. Then I do the same with our other partners. It is our company’s software pulling and pushing data to the banks and partners. We own that process. We manage that process. We must support that process.

This level of integration within the Center of the Internet, the protocols that allow us to share data at light-speed, the shared interdependence of commerce is The Cloud.

Amazon Web Services (“AWS”) recognizes 2006 as a starting point for several cloud-based services by 2016, cloud-based computing and a real sense of trust of the wire-speed services between vendors gelled. In the early days, it was exotic and expensive to be at the Center of the Internet. In 2020, it is likely the cheapest and most efficient way of providing data services to any organization for nearly any reason.

In future chapters, I will explore the Center of the Internet, the technology there, the tricks of the trade, and the clever tricks used to make it efficient.