For Non-Technical Founders
It’s been a little over a year since I last posted here, and for that, I am sorry. I have been thinking a lot about what this space should be about, and along with the founding of this space around Technology and Design, I will expand this space into helping non-technical founders. For most of my professional career I’ve enjoyed talking to and using insight from non-technical co-worker to push the state of the art forward. I’ve always enjoyed the synergy and ideation that occurs when a strong technologist and designer combine with a non-technical person. The expansion and riffing of new ideas is exciting and invigorating. To that end, here is to a new year of posting thoughts and ideas.

Thank You
Jim ‘The Designatic’ Tyrrell

Please like, share, and comment if you liked this article.

Subscribe now

Fractional CTO February
For the month of February, I will explore the concept of a Fractional CTO (Chief Technical Officer) and the benefits of hiring one for your SaaS offering.  I will touch on various themes, types, and topics around Fractional CTOs.  Feel free to share this with anyone in need of one, or someone looking to become one.  This week's post defines the ways in which a Fractional CTO can be compensated.  

The Challenge of the Fulltime CTO
When you are a non-technical founder and do not have a technical co-founder, you may think you need to hire a full-time CTO to handle the required day-to-day and ongoing technical decisions.  This might seem like a straightforward decision, but it is fraught with many challenges and pitfalls.  Bringing on a full-time CTO could be very expensive in terms of cash outlay, and the amount of equity they will require.  In addition, the vesting schedule for that equity is likely to be 3 or 4 years, which means they might stick around far longer than you want them to.  When you have a 3 or 4-year vesting schedule, full-time CTOs not working out for you may stick around a lot longer than you would like.  The hired gun, full-time CTO, may not have the commitment that you as a founder will have.  The full-time CTO, unless vetted very carefully, may not have the hours of mastery required to lead and inspire your team.  Why pay for a full-price, full-time CTO, when a Fractional CTO can be employed to prevent these challenges, while also providing many advantages?

Time Commitment
By its very nature, the Fractional CTO is a part-time resource dedicated to the technical success of your SaaS.  They will get you to market faster, than just you on your own.  On a daily basis,  they will be available via Slack or a similar platform and they will host standup meetings to remove blockers and troubleshoot challenges.  Weekly, they will have standing meetings with senior leaders for guidance and counsel.  Monthly, they will ensure strategic goals and direction are being reviewed and pivoted as required.  Quarterly, they will provide status updates and report on OKRs (Objective and Key Results) for the technical organization.  Yearly, they will participate in long-term goal setting, which is then revisited on an ongoing basis with the senior leadership team.  Basically, the Fractional CTO protects non-technical founders from the technical things they do not know.  In the beginning, the Fractional CTO is setting the cadence and way of working for the developers, but is also setting the expectations for the non-technical leaders in the organization.

Compensation
As mentioned earlier, a dedicated CTO for your startup will come with a significant equity outlay along with a significant salary.  By hiring a Fractional CTO, you can leverage a small amount of equity (2-10%) generally vesting in a year, and a monthly retainer ($2-$20k or more a month) depending on the scope of services provided.  The Fractional CTO gets to work on a few projects at once, which for the right person, is very energizing, engaging, and fun.  It also allows them to spread their risk across a few companies, and create a few lottery tickets with possibilities for multiple exits.  At the same time, you as the founder get to protect your equity and manage your cash flow.  It’s a  win-win for all involved.

Cost
The most expensive software development in the world is the one without clearly defined outcomes and metrics to track success.  If you rely on a single part-time developer or an oversubscribed agency, instead of a Fractional CTO, it is so easy to pour money into development that doesn’t lend itself to success.  By mentoring a dedicated team of developers, your Fractional CTO will keep your team on track, set them up for success, and prevent mistakes and errors a non-technical founder might learn the hard way.  The Fractional CTO is there to prevent you from killing your Saas via simple errors.

Fractional CTO
The Fractional CTO gives the SaaS founder many advantages, including:

• Less equity outlay

• Lower upfront costs

• Faster time to market

• Protecting the non-technical founder from themself

Thank You
Jim ‘The Designatic’ Tyrrell

Please like, share, and comment if you liked this article.

Subscribe now

Fractional CTO February
For the month of February, I will explore the concept of a Fractional CTO and the benefits of hiring one for your SaaS offering.  I will touch on various themes, types, and topics around Fractional CTOs.  Feel free to share this with anyone in need of one, or someone looking to become one.  This week's post defines the roles a Fractional CTO can have in an organization.  

Right Hand to the Founder
The Right Hand Fractional CTO will take the founder's ideas and vision and make them a technical reality.  Everything technical is on their plate, including the technical architecture and where it  should run.  The Right Hand will also build a software team that the CEO can rely on in order to scale the offering.  It is critical for the Right Hand Fractional CTO and the team they hire to build a sound technical foundation so that the business can scale with speed and agility.  In order to build the foundation, the Fractional CTO will leverage Design Tradecraft, like the 10 Types of Innovation and Service Journey Maps, to ensure a successful and impactful Human experience.  This rounds out the core activities of a Fractional CT as the Right Hand to the Founder.

SaaS Rescue
It’s possible for a non-technical founder to get in over their head.  If you ever watched the A-Team, you know that  “if you have a problem, and no one else can help, if you can find them, maybe you can hire,”... a Fractional CTO. 

A few of the most expensive problems when starting a SaaS include:

• Working with over-scheduled agency employees who are not dedicated to your delivery and success

• Making poor decisions around the  technical architecture 

• Failing to address the needs of users where they are, and instead guessing at the needs of users according to where the technical team hopes they might be

• Not understanding the ramifications of technical decisions or speaking a different language than the developers

As a long-tenured technical person, a SaaS Rescue Fractional CTO can sniff out these problems in minutes, and provide expert guidance to get your SaaS offering back on track.  By interviewing your current team, they can uncover the competence of the delivery team, and figure out if they are salvageable.  The Saas Rescue Fractional CTO can help rein in and provide guidance for future technical decisions and course-correct prior mistakes.  They will provide the skills, leadership, mentoring, and processes necessary to update your offering in a sound and robust way.  In addition, they will coach or remove team members that are not delivering at the level necessary to grow your business..     

Team Build Out
For the offering that is sailing along with a non-technical founder, and everything is mostly going well, a Fractional CTO can be used to help build out the team to deliver scale and capability.  A Fractional CTO will have a solid background in interviewing and hiring developers  They have developed a 6th sense that allows them to suss out the posers from the very capable developers available in the marketplace.  Finding those developer diamonds in the rough is so important for rounding out a successful and highly-functional developer team.  Injecting the right perspectives, processes, and skills into the existing developer team, while not breaking the existing capabilities and delivery is the key success marker for the Team Build Out Fractional CTO.

Fractional CTO Founder
The natural state for technical developers is curiosity and creation.  As a Fractional CTO Founder, you have a technical vision or offering you think the world needs.  However, the technical founder typically has a few gaps, including:

• Marketing

• Product Market Fit

• Sales

• Copywriting

• Contracts

• Website Development

Hiring, and finding partners or mentors to close these gaps is paramount for ensuring your success as a Fractional CTO founder.

Mentor
The Fractional CTO mentor provides dedicated phone, slack, and/or text-a-friend support and mentoring for a SaaS leader.  Oftentimes technical team members are using jargon and terms that might not be clear to the non-technical founder.  By providing the decoder ring, and being a sounding board, the Mentor Fractional CTO will provide translations and become a sounding board so that the non-technical founder isn’t taken advantage of by someone masquerading as a smart developer.

CTO Augmentation
Chief Technical Officers and senior technical leaders are sometimes tasked with initiatives or improvements that they may not have the skills or the team to deliver on. A Fractional CTO can provide the skills needed to take on new and exciting projects while leaving the existing team alone and letting them continue to do what they do best.  They may also bring an existing team to solve the challenges of the CTO.  The CTO Augmentation Fractional CTO can also coach the technical leaders on how to scale new projects with the existing team. 

Due Diligence
A Fractional CTO can provide guidance to a non-technical leader looking to purchase an existing SaaS.  There is a fair amount of technical due diligence to be conducted.
Due diligence includes:

• Interviewing existing developers

• Reviewing development and deployment processes

• Auditing technology stacks

• Providing insights into the current state of the Design

• Reviewing scale and future capabilities

• Providing recommendations for growth and a technical future for down the road

With the time spent, insight gathered, and feedback delivered, the purchaser should think about bringing on the Due Diligence Fractional CTO as a permanent Fractional CTO as the senior technical advisor and leader.

As you can see, a Fractional CTO can be beneficial in many different capacities.  But the list above is by no means an exhaustive list of the types of Fractional CTOs.  If you are using a Fractional CTO in some other capacity, I’d love to hear about it.  

Thank You
Jim ‘The Designatic’ Tyrrell

Subscribe now

Fractional CTO February
For the month of February, I will explore the concept of a Fractional CTO and the benefits of hiring one for your SaaS offering.  I will touch on various themes, kinds, types, and topics around Fractional CTOs.  Feel free to share this with anyone in need of one, or someone looking to become one.  This week's post defines a Fractional CTO and their skillset.

Senior Leader 
A Fractional CTO has various roles as a senior technical advisor and the right hand of the founder or CEO.

The Fractional CTO is:

• Tasked with ensuring that the technical decisions are sound

• Ensures technical applications, patterns, and practices are implemented

• Provides guidance and lessons learned from at least a decade of experience as a SaaS leader

• Extends, enhances, and furthers the vision of the founder

• Creates and mentors a team of software developers, architects, and designers

Software Architect with Business Acumen
With a decade or more of experience as a Software Architect leader, a solid Fractional CTO  will have many diverse experiences to call upon to ensure sound technical decisions are made.  The Fractional CTO must ensure the appropriate technology is used in all scenarios and must decide when to “build” vs “buy”.   Every line of code purchased instead of developed is one less line of code that will require debugging and support in the long run.  Ensuring that the software you are creating, and thus supporting, is delivering real differentiation is a metric to use when making the “build” vs “buy” decision.  (Seet this blog post, Build vs Buy for more on build vs buy).  A Fractional CTO must have an eye on the business’s profitability as well; and be able to work with other senior leaders to manifest and set the business vision while keeping limitations (time, money, and feasibility) top of mind in decision-making.  Providing “adult supervision” for the software architecture for stakeholders and team members is a core capability required to ensure the project stays on track.   

Technical Conscience
Another important skill is that of Technical Conscience or BS detector.  A Fractional CTO  must make sure that the right technical decisions are made, and that the technical foundation is strong, while also malleable.  Sometimes it can be slightly cheaper to select an inexpensive hosting provider, but going with one of the hyper-scalers and their worldwide reach of infrastructure delivery is a better decision for the young SaaS organization. The Fractional CTO will make recommendations around programming languages, runtimes, databases, data storage, and networking.  They must also ensure important practices like separations of concerns, modularity,  and sound object-oriented principles are followed by all.   As the code base matures, a Fractional CTO will ensure success by ensuring test cases are created.  A technical conscience developed over the years in the software development industry will inform a Fractional CTO’s decision-making process when weighing technical decisions against tradeoffs and making sure the architecture supports the upgrading of technology as new and improved ways are developed.  Acting as a Technical Conscience will prevent countless errors and mistakes, and keep the software project on track.

Chief Error Preventer
The Fractional CTO is responsible for ensuring errors are either avoided or quickly mitigated.  They will create procedures for gathering metrics and implementing proper processes like CI/CD (continuous integration and continuous deployment) into the developer's workflow.  Doing so ensures two things.  First, it ensures that all software deployments follow a repeatable process.  Second, if an error occurs during deployment, rolling back or rolling out a new update is quick and painless.  A Fractional CTO will implement appropriate testing and validation of software updates, before pushing updates to users.  Building repeatable software development processes and updates will prevent errors and downtime for the SaaS offering.

Team Builder
}Like a conductor for an orchestra or a coach for a sports team, the Fractional CTO’s job is to find the best person to put into each of the needed positions.  Hiring for diverse opinions, experiences, and development backgrounds helps ensure that ideas are challenged, implemented, and then manifest as their best implementations.  The Fractional CTO will develop a consistent set of questions to vet potential team members.  And once the team is in place, the Fractional CTO must be a great mentor.  Balancing pushing people to greatness while avoiding burnout is an art practiced by the best Fractional CTOs.

Designer 
The top Fractional CTOs will use the methods of Design to create the best experiences possible for users.  They will have empathy for end users and will use proven research methods to gather ideas to improve the offerings.    Defining and following a repeatable process to gather this feedback and bring it to the development team for implementation is the least celebrated role of the Fractional CTO, but it is paramount for the successful delivery and ongoing improvements to the offering.  The days of innovation coming on down from the Catherdral (smart engineers and leaders toiling in a cubicle) are long over.  It is only through the robust use of Design Tradecraft that you can lower your risks and costs when measured against the time and money it takes to deliver new innovative capabilities, while simultaneously defending the offering from the competition.  

The Fractional CTO wears many hats, and the skillset above is by no means exhaustive.  Everyone technical might not be cut out to be a Fractional CTO, but for those that can deliver, their future is very bright.  What are other skills that your organization requires in a Fractional CTO?

Thank You

Jim ‘The Designatic’ Tyrrell

Subscribe now

Wow, post number 20.  I hope you are enjoying them as much as I am.  

Please like, share, and subscribe if you are.

Not That Long Ago
Just a handful of years ago, if you wanted to stand up a website or some sort of mobile application, you needed to purchase millions of dollars worth of hardware and data center space, and then hire a small army of technicians to get everything running.  Today, that same capability can be procured with a swipe of a credit card, and might even be free for the first year with any number of hosting providers.  And, there’s no need to hire your own technicians because countless providers have emerged that do all of this for you for that swipe of a credit card.  But, as with anything, there are pitfalls and risks.  Let’s get into what you should be aware of to mitigate some of the risks.

Security
Taking a page from secret and covert organizations the world over, giving your users and stakeholders the minimum amount of information and access is key to lowering the attack surface for hostile actors bent on doing you harm.  Granting access and capabilities to a limited number of roles just makes sense.  In a world where the inadvertent saving of access keys to GitHub, can lead to $100,000s of billing in a matter of hours, it is essential to make sure that people's access is in line with what they need to do.  You are asking for problems if you give every account in your organization access to everything.  Give your developers the access they need and no more.  While this might slow you down a bit, having 100s of crypto miners spawned via some credential leakage is a headache you don’t want to take on.

Cloud Bursting
The benefit of the cloud is that you only have to pay for the capacity you use.  The biggest headache is that you pay for the capacity you end up using.  In a world where serverless functions, automatic provisioning, and every megabyte out (and in some cases in), are measured and billed, it can be terrifying to have a service run amok while you are asleep.  The web is filled with stories of a slight misconfiguration racking up 10s of thousands of billing when a service runs recursively.  Service A calls B calls C which then calls A can get expensive quickly.  Being mindful of what might happen and protecting against the endless calling or provisioning of computing, and installing circuit breakers to prevent runaway billing loops is a key architecture consideration.  Preventing runaway processing is always key to protecting the precious resources of your organization.  Some providers allow you to program alerts or stoppages at specific billing thresholds. 

Architecture, and preventing lock-in
All of the hyper scalers have countless building blocks for your software idea.  However, it’s important to be mindful of what you should buy vs build, along with how you might replace or move away from a purchased service down the road should your needs change or technology evolves.  But there’s always the other side of the coin where you, as a technologist, will be called on to support something for far longer than was anticipated.  Ensuring you have the ability to pull the ripcord and move your stack to another provider will at least get you thinking about future-proofing architecture decisions.  Being mindful of the billing consequences of your decisions should always enter into the calculus when figuring out what to purchase and deploy.

Using the cloud does not have to be dangerous, but like any number of activities, you should think about the consequences of your architectural decisions.  Ensure your developers and administrators have just enough access to do what they need to do, will prevent runaway access from hurting you.  Thinking about how to leverage the cloud’s bursting capabilities, while also preventing services from running wild on your billing.  Finally, think about if your architectural decisions will lock you in or allow you to grow.  And, always think about an escape hatch if something becomes untenable as your needs, billing, or architecture decisions evolve over time.

Thank You
Jim ‘The Designatic’ Tyrrell

Subscribe now

Design December - Drifting into January as I didn’t get everything out that I wanted to.
I’ve written a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many research models based on repeatable methods.  Before I end Design December, I want to speak about the final model that helps to ensure the completeness of a vision.  As technical leaders, it is so easy to forget that your creations need more than just technical acumen.  Luckily, the Ten Types of Innovation has an area dedicated to us but also asks us to include Designers and Business people in the creation and implementation of our ideas.  The Ten Types of Innovation is a nearly 25-year-old methodology that helps ensure the inclusion of typical stakeholders, which enables us to create robust services and lets us measure ourselves against our competitors.  Like the Balanced Breakthrough model from last week, this stems from groundbreaking research and delivery from Larry Keely and our friends at Doblin.  Let’s dive in.

Ten Types, a brief overview 
From the image above, you can see three main broad categories of Configuration in blue, Offering in gold, and Experience in red.  Looking further you will see that Configuration has 4 categories, Offering has 2, and Experience has 4.  When fostering innovation, as Larry says, we need to create“... bolder concepts, that are easier to implement and harder to copy.”  We do this by using each of the 3 colored groups and 5 or more tactics.  When we do this well, we create a better and more profitable business and offering for ourselves and our customers.  Let’s dive into each of these 3 areas just a bit more.

Configuration
The tactics in this area are taught in MBA programs and are the building blocks for business.  With the 4 types of Innovation: Profit Model, Network, Structure, and Process we explore the different ways we organize the delivery of our offering to the marketplace.  Including how we price our offering, how we go to market, where we acquire our offering, how we might produce it, and so many more.  I have linked the complete list of tactics here for you to explore.[1]

Offering
The Offering area is mostly taught in university Engineering programs.  These types of Product Performance and Product System, ask us to explore what is possible with new technical innovations.  What can we do today, that we could not do yesterday, and further, what competitive unfair advantage do we have over our competitors?  What kind of new experiences can we create for our users, and what elegant integration can we deliver to make a platform, more on Platforms in just a bit.   

Experience
Finally, Experience skills are taught in Social Science or Design schools. Across these four types of innovation: Services, Channel, Brand, and Customer Engagement we focus on the User Experience but also sprinkle in brand-building ideas.  With Services, we explore how we might more thoroughly and robustly engage with our customers, via loyalty or rewards programs as an example.  Channel, has us exploring how we will go to market and which partners we might align with.  Again explore all of the tactics with this link[1]. Also, remember you need at least 5 tactics across all 3 colors.

Creating Leading Platforms
I mentioned the idea of Platforms above and wanted to explore that a bit.  The Ten Types of Innovation is a great method to develop a robust platform for your offering or service.  As we enter into a new era of innovation and development, and as Mauro Porcini, the Chief Design Officer at Pepsi says, we are entering an “Age of Excellence.”  With a new experience just a swipe away, delivering robust, well-thought-out ideas into the marketplace is key to surviving the long tail of innovation.  Delivering “... bolder concepts, that are easier to implement and harder to copy”, will be the key driver for successful companies moving forward. 

Thank You
Jim ‘The Designatic’ Tyrrell

[1] Ten Types of Innovation Tactics:
https://doblin.com/dist/images/uploads/TenTypesInnovation.pdf 

[2] One of the several great talks by Larry Talking about the Ten Types of Innovation, enjoy

Subscribe now

Design December - Drifting into January as I didn’t get everything out that I wanted to.

I’ve written a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many research models based on repeatable methods.  Before I end Design December, I want to speak to two models that help to ensure the completeness of a vision.  As technical leaders, it is so easy to forget that your creations need more than just technical acumen.  They need to be complete and fully formed for the marketplace.  Let’s explore the Balanced Breakthrough model of Feasible, Desirable, and Viable.  This was created by Larry Keely and Doblin in the early 2000s and referenced in one of my favorite books on Design, “The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity”[1].  In a talk Larry Keely gave in April 2020 he added Sustainable.  I have added Ethical and Inclusive to round out 6 key elements you should be thinking about when creating and innovating something new.

Feasible 
First, we have entered an age in which nearly any technical idea is possible, save for some very compute-intensive problems around AI and ML, and those boundaries are slowly eroding as evidenced by ChatGPT.   In many ways, at least online, the technical challenges of a decade or two ago are solved with a credit card and an account at AWS.  The foundations for your project are available for free to anyone with an internet connection, from millions of open-source projects hosted on GitHub.  The internet has enabled the sharing of ideas on a scale that is so enormous it’s tough to quantify, yet technical founders sometimes believe that creating the next technical innovation will lead to victory.  However, because all of these software building blocks create a ton of homogeneity, your outcome without some other thinking injected into the equation, at best trends towards the average and mediocre.  How can you overcome this technical bias? I’ll introduce 5 more parts of the Balanced Breakthrough model to give you a more robust and complete way to introduce, complete, and compete with your innovation.

Viable
Second, let’s explore the viability of your offering.  At the end of the day, unless you are independently wealthy, or funded by a benevolent sponsor, your ideas need to make money in the marketplace.  Like the use of hosting on AWS mentioned above, the ability to fund your idea via Kickstarter, advertising, micropayments, subscriptions, or patrons has never been easier.  Collecting money with any of these models is the easy part.  Finding that elusive product-market -fit, for an idea at the scale required to return the investment you and your sponsors have put into your idea, is the hard part.  Finding something that is unique enough, differentiated in the marketplace, and isn’t just a derivative me too offering is the difference between winning and losing.  Forgetting that the idea needs to make money to support its ongoing operations has sunk many SaaS offerings.   

Desirable
Third, now that you have a technical and financial plan, ensuring that the users of your product are happy and will continue to do business with you is your next concern.  If the offering does not have some compelling features that take it beyond what is already available in the marketplace, why are you bothering to create it?  Finding Ethical, more on this in a bit, ways to be sticky with your users, and making sure they want to come back, will go a long way towards making sure your users are happy with their purchase.  Having solid User Experience and ensuring the next best action and the experience is curated for them will ensure your users are happy.  When you get this right, your existing customers will become your biggest cheerleaders for your offering, and you will know you have arrived.   

Sustainable
Fourth, against the resources of the planet, is your offering being as light as it can be with the compute it requires?  I have great challenges with Bitcoin and other proof-of-work algorithms that use the equivalent amount of power as some small nations in aggregate.  Being as efficient with the code we deliver and ensuring we do not use more resources than required should be a requirement for anything that we ship.  Continuing to watch and ensure systems are as efficient as possible, is on all of us as software creators and maintainers.

Ethical 
Fifth, we are well aware of any number of scandals around the use of social media to sway the opinions of citizens or to not treat others with respect and dignity.  While we can use software and many models and technology for behavior change, we must ensure that we do this ethically.  Tricking people into buying something, promoting unsound or unscientific thinking, and creating an echo chamber are some of the worst aspects of technology, that we as leaders need to corral to ensure we are delivering our offerings in an ethical way.  By leveraging the golden rule, of treating others as we want to be treated, we can mitigate many of the dangers possible via the unethical implementation of technology.  

Inclusive
Sixth, our world is full of diversity.  Humans come in all shapes and sizes, and have different education levels, different thoughts, and ideas, and different abilities and challenges. In other words, humans are super unique beings.   Because your users are human, they will be super unique users.  It’s important to take into account the breadth and diversity of your users so that they may all experience your offering in the way it’s intended.  To only target our technical selves, is the quickest way to alienate vast quantities of those that can be helped by the technology that you are creating.  

By using the Balanced Breakthrough model, and thinking about how to use the thoughts of Feasible, Viable, Desirable, Sustainable, Ethical, and Inclusive above, you will ensure your offerings are as complete as they can be in order to effectively compete in the marketplace, and ensure you continue to innovate and do what you do best as technical leaders.

Thank You

Jim ‘The Designatic’ Tyrrell

[1]  https://www.amazon.com/Inmates-Are-Running-Asylum-Products/dp/0672326140

Subscribe now

Design December
I’ve written a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many research models based on repeatable methods.  I will focus the next several posts on this type of Design.  I recently listened to a podcast[1] and it reminded me of several tips or keys to keep in mind when observing or interviewing users, and capturing their feedback.  As technical leaders and software developers who have spent countless hours creating your offering,  our natural biases give us tremendous ownership of how it works, and please remember that feedback against this feeling of ownership is a gift and not an indictment of your capabilities.

Subscribe now

Feedback Early and Often
Like voting in a Chicago election, we want to get feedback early and often.  This feedback should not be from the direct stakeholders and/or sponsors.  Instead, it should come from independent, outside parties.  It is only when we open ourselves up to these outside influences that amazing things can happen.   A fresh set of eyes and an outside perspective will always give you insights into how things are progressing with your creation.  Getting feedback on each iteration and update ensures that you don’t stray too far from the needs and wants of real humans.  With that said, there is always a certain amount of entrepreneurial license that needs to be undertaken, however, this does not free you from getting feedback early and often.  Slight course corrections are always easier to incorporate versus a complete change of course after weeks, months, or years have gone by.

Feedback Cadence 
Now that you accept early and often feedback is important, how often should you get this feedback?  Like the drummer in the marching band, it is imperative that you create a consistent cadence of capture.  In my experience, letting anything linger longer than a week is far too long.  In reading about other organizations, getting and implementing feedback every other day on Tuesdays and Thursdays would be an advanced step.  Having scheduled sessions with those outside contributors does a few things.  First, it gets you on a schedule to learn.  Second, it gets you used to hearing and seeing feedback.  Third, it allows you to course correct before you are far too committed to an idea.  Fourth, it gets you used to listening and comfortable with feedback on your ideas, which if you take anything from this article, is never an indictment of you.  Fifth, it gets you and your organization thinking about how to inject and take in this feedback with empathy for your ultimate end users and consumers.  Having a schedule and sticking to it, is the quickest way to learn and gain the insights necessary for delivering software in this modern world.

Feedback with Grace
Accepting feedback with grace can be difficult for most humans.  Being wrong or incorrect is often associated with bad grades in school, losing out on opportunities, or just a general feeling of unease.  In the team sport that is software creation, it is imperative that you lose this bias and fear.  Remember your feedback session is a gift from the giver to you, and of course,  you should not look a gift horse in the mouth.  Sitting back and respectfully taking in all of the things the giver is giving you is key.  Ensuring you don’t correct or give them any guidance is a hard thing for an observer but is the most important tip for ensuring the feedback you receive is genuine, actionable, and without biases, you can easily inject into the conversation.  Just sitting back and listening will allow you to receive so much more, which in this case is the most important item. 

Feedback on Feedback
If you are asking people for feedback, especially if they are teammates, or others close to you, you owe it to yourself and them, to take in that feedback with grace and humility as just noted.  If people have taken time out of their day, and have injected their experiences and observations, it is a good idea to circle back with them and talk about how their feedback influenced your offering..  This does two things.  First, it shows them that you listened to what they had to say.  Second, it gives both of you time to explore the feedback and ensures you really did hear them.  Just because they said to do this thing, sometimes, what they are asking for can more easily be addressed with a simpler or easier change.  Allowing them and you to see the outcomes of the feedback, will empower future feedback sessions with deeper and more profound feedback for all.  

Receiving feedback is a muscle like any other, and exercising it on a schedule, early and often, with grace and follow-up for the giving party, will supercharge your software creative efforts.

Thank You

Jim ‘The Designatic’ Tyrrell

[1] https://www.usersknow.com/podcast/2015/12/11/your-research-character

Design December
I’ve written a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many research models based on repeatable methods.  I am going to focus the next several posts on this type of Design.  When I speak with software leaders, they often tell me that they think of User Experience as opinions and that measuring it is nearly impossible and is just a huge time suck on the project.  But I say it’s not just opinions and there is a way to measure it.  The folks at Nielson Norman group[1] have an excellent method to assess the User Experience of software.  Using their method you can make an experience you are proud to deliver, customers are happy to use, and most importantly one they will promote.  It’s a Design method grounded in science and user observations.  This method has 5 simple questions to address and assess User Experience.

Learnability 
This question could also be labeled discoverability or curation.  Can the user simply and easily look at the user interface, and successfully get to their desired outcome? Note I said their desired outcome, not your desired outcome.  In other words, how many users in the general pool will be able to complete a task successfully?

Efficiency 
Once those users are experts at the system, how easily can they accelerate their performance and do things very quickly?  Will it be easy to memorize the steps or are there keyboard shortcuts to accomplish tasks very quickly?  Or can they clone existing working items and modify them slightly to get new capabilities accomplished?  

Memorability 
This is often where software delivered on the web falls down.  If your users have not been to your offering in a while, will they immediately know what to do?  How much of your user interface has changed or has the perception of change from the last time your user visited weeks or months ago?   In other words, when they come back how long does it take them to get to the accomplished levels of production they had when they first learned the offering?  Subtle User Interface(UI) changes add up to significant changes over time for a user who seldom uses your offer.

Errors 
When a user does something wrong, is the next best corrective action offered, or are they expected to troubleshoot the errors they’ve uncovered?  Having an undo capability or start-over feature will enable users to go back to the last known good state before they started making changes.  Helping users to prevent errors should be your first goal.  Humans are creative and crafty and good at breaking things or finding ways in which your offering falls down.  Logging errors that occur, and ensuring remediation is provided for your users with future updates, lets your users know that you are considering their needs and designing for empathy.  

Satisfaction 
Are your users happy and content with what they accomplished?  Are they willing to tell others about the experience and promote your offering to coworkers and friends?  Having power sponsors and other advocates for your offering will turbocharge your adoption.

1 Tip:
User Experience and Design can be a science, testing users against the metrics of Learnability, Efficiency, Memorability, Errors, and Satisfaction will go a long way toward giving your teams a repeatable method to uncover the quality of your user experience.

Thank You
Jim ‘The Designatic’ Tyrrell

[1]
https://www.nngroup.com/articles/usability-101-introduction-to-usability/

Subscribe now

Design December
I’ve written a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many research models based on repeatable methods.  I am going to focus the next several posts on this type of Design.  My next two posts will speak to observing users.  Let me introduce the POEMS method.  This method of user observation will result in insights and game-changing innovation for your users and organization.  Like many methods, this one is based on products delivered in the physical world, so I’ve used some artistic license to convert it to the digital world.

POEMS 
People, Objects, Environments, Messages, and Services or POEMS, is another great way to give your observations and insight gathering a baseline and way of working across a disparate team.  The model ensures everyone on the team uses the same user observation framework and defines common buckets to start with when doing classification and normalizing your insights during analysis and synthesis.  Inside these observations will be key insights to drive your innovation projects.  It is really hard to define a key insight, but you will know it when you see it.  It can be defined as that eureka moment, when you find a core reason something is happening, or can model the challenge before you simply and elegantly.  Breaking down observations continually is key to getting deep into your insight gathering.  You will see some overlap with the AEIOU framework from last week, which is common among Design methods.

People
For the purpose of this method, People is defined as the demographics, titles, and roles of your users, as well as the activities performed by the users during your study.  The prior education, training, and experiences of your study participants, will color the expectations and biases they bring to the activity.  Understanding these biases will give you deep insights into the makeup of the users of your offering.  Stressors and other friction elements your people are experiencing are also important to look at and make note of.  Getting deep into who your people are and what makes them tick is key for this element.

Objects
In our digital world, we often forget about the number of different tools our users will be using.  These tools include phones, tablets, notebooks, and desktop computers.  Each of these devices influences the kind of activities your users should be expected to accomplish and where they will occur.  Each device type has unique delivery capabilities and implied ways of working.  For example, tablets and phones can have swipes and other gesture commands that may not work on notebooks or desktops. I’d be lying if I said I haven’t tried to swipe the screen on my Mac.  On a few occasions, I’ve used a swipe on my Mac while using an application that has many of the same visual queues as the phone or tablet experience.  Of course, that shows poorly laid out wayfinding or curation on the part of the creators.  

Environments
Beyond objects, we need to consider the environment our users are in.  We should think about the lighting, noise, temperature, desks, chairs, and anything else that makes up the physical space of our users.  Getting into their environment is admittedly more challenging in a Covid reality, but necessary to allow you to see and feel the way in which your users are living and working with your experience.  People's homelife and home offices affect their experiences and should definitely be included in your observations.

Messages
Your users will communicate with other users as they work. Watching and listening for common words, phrases, and other verbal and non-verbal cues will give you a sense of how your users are feeling as they interact with your offer.  Are their interactions professional and seemingly orchestrated, or are they haphazard without coordination?  What codewords, abbreviations, acronyms, and other tribal knowledge are being leveraged in communication between parties?  With computers, it is so easy to forget there is a treasure trove of information shared in emails and chat, and we should work hard to uncover those messages to gain real insights into the feelings of our users.

Services 
Finally, we should think about the documentation the user is using, either their own or provided.  We should also take note of any other software tools people are integrating to complete their experience.  What frameworks or tools have been created by the user for success, or what mental models do they bring from past use to ensure their or their team's success?  Who are they reaching out to for help, or what google searches or videos are they watching to complete the tasks?  

1 Tip:
Use the POEMS, Think about what your People are doing, think about the Objects they are using, look at the Environment, check out the Messages they use with each other, and the Services they bring to solve the things they are trying to accomplish.

Thank You
Jim ‘The Designatic’ Tyrrell

Subscribe now

Design December

I’ve written a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many research models based on repeatable methods.  I am going to focus the next several posts on this type of Design.  My next two posts will speak to observing users.  Let me introduce the AEIOU method.  This method of user observation will result in insights and game-changing innovation for your users and organization.  Like many methods they are based on products delivered in the physical world, I’ve had to use some artistic license to convert it to the digital world we all inhabit. 

AEIOU 

The AEIOU method is just one of a hundred methods documented in Vijay Kumar’s amazing book, 101 Design Methods[1], which celebrates its 10-year anniversary at an event I will be attending later this week. I have used this framework countless times to uncover what is really challenging for end users and to find the space for innovation in a product or offer. And, it ensures I uncover what users need instead of what I think they want (or even what they think they want).  As Henry Ford joked, if he had asked people what they wanted, they would have said a faster horse. Let’s explore this method to help you uncover key insights for driving your innovation practice, and making something more desirable for your users than a faster horse.  By the way, AEIOU stands for Activities, Environments, Interactions, Objects, and Users.

Activities

Your code has zero value until it’s shipped.  Worse, if the time for users to see value in your software is too long, you will have an exodus of users.   Finding the sweet spot of what your users will pay for, the value they get from using your software, and your ability to deliver in a timely, and cost-effective manner is the holy grail of software development.  Asking questions about what it is your users are trying to do, and observing them is key to uncovering the friction they experience and is innovation gold for your organization.  Figuring out the user’s next best actions and gathering key insights by seeing live actors doing activities will put you far ahead of your competition.  If you are looking for a place to start, check out the users’ notes, spreadsheets, emails, chat messages, and other documentation your users are keeping that is outside of your offering to uncover areas to improve. 

Environments

The pandemic forced many users into home workspaces and offices. With this change of venue, people are working differently and your offer has to accommodate people where they are.   Are your users always being interrupted via slack or messages?  Do they have the space to get work done?  The environment can also refer to the physical space your users are working within,  and also to the devices they are working on, phones, laptops, and tablets.   How does your offering facilitate the integration of teams working remotely and on different platforms?  Google docs make it incredibly easy to collaborate as part of a team. How can your innovations drive more distributed collaboration and teamwork seamlessly across devices?  Discover the friction in the environment, both what you can and can’t control, is creating for your users and you’ll further inform areas for innovation.

Interactions

How do your users interact with your offering?  What are the workflows or communication patterns between users and software?   Are they creating unintended workflows?  Are they performing actions outside of the designed and curated experience?  Do they have to go outside of your offering to some other software to accomplish their end goal?  Uncovering the answers to these questions will give you information about where to take your innovation next.  

Objects 

In a perfect world, your software is completely intuitive. But in reality, your user is likely going to need to use some sort of object to help them use your software.   Will they need to read documentation, look at knowledge base articles, or phone a friend to accomplish some task within your offering? How will a new user learn your software without tons of painful trial and error?  It is in this space, that a lot of friction lays, that many improvement opportunities live. 

Users

Your users are nowhere near as invested as you are in learning the ins and outs of your offering.  On any given day your users interact with 100s or even 1000s of user interface components. Expecting them to be masters of each is bound to create dissatisfied users. Finding out what really makes your users tick, along with understanding their limitations, and really getting at their core needs and desires will give you a leg up when driving innovation.  At the end of the day, every user makes a decision based on emotions, and as I like to say good emotions are the grease for human decision-making.  Understanding what users really need, instead of hoping to meet their needs, is the difference between a winning innovation strategy and being an also-ran.  Watching and really listening to your users will give you the key insights needed to deliver compelling offerings for them. 

Assuming that you know what your users need or want is the quickest way to fail.

1 Tip:

Use the AEIOU

1. Activities: What is it that users are looking to accomplish?

2. Environments: We are all working on disconnected, asynchronous teams, and on multiple devices. What does that mean for your users?

3. Interactions: How many people and systems are touched to get the work done?

4. Objects: What are people combining to enable them to accomplish their work?

5. Users: What makes your users tick, and how invested are they in memorizing all the nuances of your offering?

Thank You

Jim ‘The Designatic’ Tyrrell

[1]  http://www.101designmethods.com/

Subscribe now

Lucky number 13 was set for publishing on Halloween, spooky.

Design December, starts a month early

I’ve written and spoken a bit about my Masters of Design Methods degree.  My design school experience was not about art, colors, layouts, or fonts.  Instead, it focused on Strategy,  Innovation, and Leadership, along with many models based on repeatable methods.  I am going to focus the next several posts on this type of Design. This first Design post is about the 5Es, a concept dating back to a Ted Talk from 1997[1].  It is a simple model to ensure you are covering the entire user journey from beginning to end, aka from Entice, to Enter, Engage, Exit, and finally to Extend.

Entice

What are you doing to attract potential users to your SaaS?  You raise awareness through general marketing, social media posts, news articles, email blasts, cold calling, and optimizing your website for search engines.  For your SaaS, the most important Enticement artifact, once potential users are aware of you, is your website.  Countless articles have been written about optimizing your landing page, calls to action, and pricing models to grab a potential user’s attention.  At a minimum, you should consider social proof, videos, pricing, and FAQs, as specific landing page content you need a strategy around.

Enter

How do first-time users sign up for your service, and have you provided an onboarding experience with as little friction as possible?  For better or worse, providing a free 14-day trial has become typical, this will give you plenty of email addresses to market to, but the rest of your experience should be tailored to converting them into a paying customer.  At this stage, you want to gather an email address and a password, that’s it.  Limiting the number of fields people have to fill out for the 14-day trial will increase the number of people completing the signup process.  All other information gathering, like credit card numbers, general demographics, and marketing questions should be pushed to later in the process.  Once you have a baseline signup process working and are driving traffic, you can make changes to the information you gather, and test whether it materially affects signup rates and/or long-term retention.

Engage

Once users have entered your application, how will they learn what your application can do for them?  Will you use quickstart videos and documentation or curate a self-discovery type of experience with step-by-step guides directing the user to the next best action?  Whichever method you employ you want, to ensure your users are as comfortable as possible with using your tool and seeing value in the experience.  Giving them ongoing feedback around their successes, and pointing them to resolving their errors on their own without magic knowledge is key for onboarding customers successfully.  And, consider showing your users how many other users are simultaneously using the application as social proof that they’ve made the right choice.

Exit

How will you wrap up an experience for your user while also encouraging them to come back?  Consider showing them what they’ve accomplished in their session with feedback and metrics.  How can you show them what they have accomplished, or can you show them metrics and other data that show others using the SaaS successfully?  You can show them how many people in the last hour, day, or week, did the same thing they just did, as an example.  By thanking them for their use, encouraging good behavior, and giving some social proof, you will encourage a return to your application.    

Extend

Remember at the beginning of the post that I mentioned that typical SaaS are free for the first 14 days?  At this point, once you have an email address, you can Extend the experience for your users, offering them more of whatever you are offering for free.  That could mean giving them a 30-day eval, more storage, or more capabilities/features. The more of your application that they dig into and you encourage them to use during the free period, the more likely they’ll be to extend their use beyond the free period.  This is the E that most technical people tend to forget, and, even if it does get addressed most experiences don’t put enough time into it.  With that said,  if you put some effort into it, it’s an easy way to differentiate yourself from the pack and retain a user beyond the trial period.  

By using the 5E model you will create curated and fantastic experiences for your new SaaS users and encourage  those new users to become long-term customers.

1 Tip:

Use the 5Es

1. Entice: Market well and raise awareness

2. Enter: Give them a reason to use your offering

3. Engage: Curate and make an enjoyable experience

4. Exit: Let people know that others are accomplishing the same thing

5. Extend: Convert to paying customers

Thank You

Jim ‘The Designatic’ Tyrrell

[1] https://doblin.com/about  Click on 1997, part way down, and you should see “Landmark User Research Method”

Subscribe now

How to Plan Your Deployment

I have been talking with some friends about setting up AWS instances and the general considerations for networking and server setup.  Two decades ago hosting an application on the internet might have been challenging and required a significant investment, however, with the advent of AWS, this became easier, and definitely a lot cheaper.  In addition, it’s easier than ever to drive traffic to your applications, and having more traffic than you can handle is a great problem to have.  But you should ask yourself, can you handle that spike in traffic quickly and easily?  What should you do from the beginning to set yourself up for scale?  This article will focus on the AWS services, but the other hyper-scalers have some of the same capabilities.  Let’s dig in.

Basic Setup

To host an application on AWS you could use 4 of their basic services to build your foundation.  The first is Route 53, which gives you DNS (Domain Name Service) capabilities.  This delivers the basics of taking a domain name, something like cloudywithachanceofsaas.com, and pointing it to an IP address bound to a server running your site.  You can provision servers, via EC2 (Amazon Elastic Compute Cloud) instances, which allow you to run the custom software you have written.  Second, you will have some sort of data store or database.  AWS has many different options, but MySQL is a tried and true offering available from within AWS RDS (Amazon Relational Databases).  I like this stack and have set it up a ton of times.   Luckily for us and where we are headed Route 53 is already highly available and bakes in worldwide capabilities.  However, there are a few things to be aware of for EC2 and RDS setups like this.  It does not have any redundancy as you only have one instance of EC2 and RDS running.  Since you only have one instance of each, software and hardware maintenance windows and doing updates is a challenge.   While you can mitigate some of this with an in-elastic IP address, and for many deployments, you can stop here.  But your users can experience slight outages as you move this IP address to a new server.  For maintenance, software, or server updates, you can inadvertently shut off access to your users.  As I noted in a prior article if you have an Application available in an app store, it should handle the backend being down for short periods, but how do you engineer a more robust infrastructure?  Enter the fourth piece of the stack, the AWS Application Load Balancer.

AWS Application Load Balancer

There are several reasons to use the application load balancer.  First, it offloads the updating and processing of the HTTPS/SSL requests from your end users.  You no longer have to have anything configured or running to keep that current.  This means you’re putting one less burden on already stretched teams.  Second, it allows you to run multiple EC2 instances to handle spikes in load and allows you to perform server updates and maintenance on your server instances without adversely affecting your end users.  Third, with the Geolocation routing available from Route 53, you can route your users to infrastructure located closer to them, giving them better performance.  At the same time, if a region has to be taken down for maintenance, or has an outage, other regions can, and will automatically pick up the slack.  Fourth, you can stand up multiple servers to handle system failures and to handle more workload.  Fifth, it allows you to stand up new instances of your software as test or validation instances, which ensures everything is running correctly before you switch all of your users over to the new EC2 instance.  While the Application Load Balancers are not super expensive, you probably just need one for your application infrastructure at the beginning of your project across the typical loads of dev, test, integration, and production.

By beginning your infrastructure layout with an application load balancer you are setting up your infrastructure for future growth and scale.

1 Tip:

1. Be ready to grow easily and simply via an AWS Load Balancer with the suggestions above.

Thank You

Jim ‘The Designatic’ Tyrrell

Subscribe now

Design Thinking

I sit on a lot of phone calls throughout my workday.  And today, during another series of endless meetings, someone spoke about the consultants they’re enlisting to run a Design Thinking workshop.  As a graduate of one of the most prestigious design schools on the planet (according to my professors), I’m fascinated and also somewhat skeptical when people say they are going to run a Design Thinking workshop., The school I attended is not about design as it’s traditionally thought of in the context of art, colors, fonts, and layouts.   Of course, there is nothing wrong with these types of design skills.   However, a Design Thinking workshop has nothing to do with these skills. Design Thinking is Strategy, Innovation, and Leadership as they relate to developing products and services grounded in end-user empathy.  Design Thinking also requires skills in Behavioral Economics, Service Design, and Portfolio Planning among many other skills.  With all of that, to be a designer, you just need a willingness to observe, find empathy, create a solution, test it, and then improve, Design school is not the price of entry.

Research - Analysis - Background

Putting a bunch of people in a room to brainstorm is clearly the easiest way to generate ideas, but is it effective?  As many say, to come up with one great idea you have to have many ideas. However, the ideas inherent in a brainstorming session held among a homogenous team without outside influences tend to be on the less innovative side.  As one of my mentors said once, ideas trend toward the average or mundane.  Creating real innovation that goes beyond just superficial naval gazing requires Design Tradecraft.  You need to do some basic research and formulate a “how might we statement” to inform your next steps.  The how might we statement is the hypothesis that you want to research and validate with real users.

Research - Analysis - Finding Empathy

By having a “how might we” statement, you establish a clear foundation and set your project up for success.    But honing in on the right statement can only come from observing people in their natural habitat.  You can’t simply ask them what they do, you have to watch them do it.  One of my professors has a story on conducting research by watching vs asking.  She asked her research subject what he does at home to work out and keep fit. The subject responded that he works out with weights nearly every day.  My professor asked him where those weights were, and the subject responded that they were in his bedroom.  My professor asked if she could see the weights, and the subject said yes. My professor reported that the weights had a ¼ inch of dust on them.  Do you know how long it takes to get that much dust on something? I am guessing it’s measured in years and the subject hadn’t actually lifted them in quite some time.

Quantitative vs Qualitative Data

By seeing the weights you now have some Qualitative data on which to ground more studies. How many projects have failed because the marketing team or engineering team brought in piles of quantitative data to the team? How many leaders make decisions purely on quantitative grounds?  It makes us feel great as leaders, armed with stats and math, however, that data is never as simple as it seems.  Understanding the why behind actions will give you countless insights into what you should create.  In other words, no amount of quantitative data, usually gathered by surveys or interviews, will uncover the key insights you need to get to the right questions.  Areas of research can only be defined by breaking down the challenges and opportunities all stakeholders have.  This journey will not be linear by definition but is always insightful to all that partake in it.  Getting out and seeing real people, doing real things, will give you countless areas to do incremental and game-changing innovation. 

Scale

You probably aren’t going to watch hundreds of users use your product.  That isn’t scalable.    However, 5-6 interviews will give you all the insights you need, and that qualitative data will be infinitely more telling than thousands of surveys. .  Zoom and other screen-sharing and recording technology make observing your user super easy.  Finding the why for your user will pay huge dividends no matter what it is you are looking to innovate on; and will certainly be more informative than simply asking your developers to brainstorm new ideas. 

1 Tip:

1. Qualitative Data is key for figuring out why someone is doing what they are doing.

Thank You

Jim ‘The Designatic’ Tyrrell

Subscribe now

Wow!!!

I started this newsletter around random SaaS thoughts that I have been having after encouragement from several different people, forces, and inspiration.  Imagine my surprise, last week, when I realized that issue number 10 would be put to bed on my birthday 10-10.  My first name is Jim and J is the 10th letter of the alphabet.  Not sure what all that means, but I’m certain the universe is trying to tell me something, what it is I am not sure.

Thanksgiving Feast

In a few months those of us in the USA will be celebrating Thanksgiving and gathering for possibly the first time with our extended families since the pandemic began.  One of my favorite stories around Thanksgiving goes like this.  A friend of mine was asking her mom how to cook Thanksgiving Ham.  The mother said the first step was to cut off the ends before it was placed into the pan and put in the oven.  She made it seem like the most important step. The daughter asked why cutting off the ends was so important and what purpose did it serve.  After several calls to various aunts, uncles, and many others, someone finally thought to call the grandmother who was getting on in years and was now living in assisted living.  When they finally got a hold of her, she told them that she cut the ends off so the ham would fit in her pan.  The moral of the story is to examine why you do the things you do.  Is it because that’s the way they’ve always been done or is it because it’s really necessary?

Multiple Environments, Development, Staging, Pre-Production, and Production, Oh My

I get this one might be sacrilege to some, but if you have a small enough team, and are moving fast enough using just one environment is all you need.  Ensuring that your teams are not bogged down with many environments (development, integration, pre-production, and production) to ensure the software they are delivering is free of bugs is usually a false economy.  I’ve never seen an organization that can move from one of the lower-order environments (Development, Integration, etc) to Production without something going sideways.

When doing these updates, the trick is always in the balance of delivering new features, against breaking things that are already shipped.s.  With adequate testing, robust microservice architecture, and well-defined and validated interconnectedness, you should be able to move fast with just a production environment when you start.  With the right use of feature hiding to mask the work you are doing right now, you should be able to move fast with just one environment and save your teams from the drag of having to push software through many different environments.  Getting the hang of architecting and delivering your system this way will allow you to go as fast as possible, while also maintaining quality for the features you eventually release to your end users.  In other words, that ham will be cooked just right without having to cut off the ends.

T-Shirt like sizing around Small, Medium, and Large vs Hours for Feature Scoping

I have been around countless projects where people will spend hours debating the number of hours features will take to implement.  In far too many cases, which is another article for the future, we have no idea how long some new capability will take.  Rather than spending a ton of time thinking about the hours to completion, how about just coding it against the metrics of small, medium, or large?  This gives us the opportunity to decide if the opportunity cost of working on that thing is worthwhile when measured against the return on investment expected for the creation and delivery of the feature.  It is so easy to spend hours or even weeks creating something that will never return the cost of creating it in the first place.

1 Tip:

1. Really think about why you are doing something and decide if it is adding or subtracting value from your processes.

2. Use the simplest scoping methods possible to decide how long something will take.

Thank You

Jim ‘The Designatic’ Tyrrell

Subscribe now

Development

As a 27+ year veteran of delivering software or being around software delivery, I am still as excited today as I was when I first began.  From Helloworld with a new library, language, or a new simple application exploring something new to me, or running some new machine learning algorithm, it is all still so exciting.  The only thing more exciting than checking out something new is creating things from scratch.  Humans are incredibly creative when given a chance, and it is this creativity that sometimes gets developers into trouble.  I know this is going to be shocking to some, but the mere act of creating software, does not automatically make it great, nor does it make it key to the success of your SaaS.  Worse, it can distract you from delivering on the key differentiation you need in a hyper-competitive industry where micro-niches abound.  In a world that delivers micro-niches for just about any background services you need for dollars, or even pennies, how can you afford to expend significant developer time and money on creating software that does not give you a competitive differentiation?   

Share

Build

Just a few years ago you had to spend a few million dollars and hire a small army to stand up a worldwide accessible network of servers, that was hopefully co-located to save some expense and was not in your own data center or down the hall in your office.  But today that same infrastructure is available for a  small monthly fee.  The hyper-scalers all provide various capabilities, but at their core, they give you computing, storage, networking, and DNS/routing to make your applications accessible to the world. This same consolidation and abstraction that has occurred in hardware and hosting, has been going on for years in software.  At this point a SaaS seems to exist for just about any capability you might need; and if it doesn’t exist, you can easily wire up a few SaaS’s to provide that capability for you.

Authentication and Authorization

At this point, you should not need to stand up or write your own services to authenticate or authorize your users.  The hyper-scalers and many pure-play vendors have capabilities in this space.  They offload the security requirements, high availability, email, backups, and many other requirements needed for storing users' emails and passwords.  For pennies a user, and in many cases, free for the first several thousand users, you can not go wrong by using one of these vendors.  You will remove a source of many headaches for your organization, and allow yourself to be built on top of a well-architected, delivered, and constantly updated solution.  At the end of the day, for all of your developer's creativity, they will never be able to match the capabilities of a pure play vendor, nor should you expect to innovate in passwords, unless that is your business.  This area and space are very mature at this point, and can easily be acquired.

Reporting, Logging and Monitoring

Centralized reporting, logging, and monitoring are other capabilities that can easily be spliced into your applications from any number of vendors.  Metrics around use and how people progress through your application is a key to uncovering patterns of use and figuring out a differentiator and competitive advantage for you.  However, having to write, create, and stand up the infrastructure to deliver always-on listeners, globally by the use of your application, is a hard problem.  Ensuring that the data gathered is secured, is yet another problem.  And of course, the analytics and analysis of that data are key for your success, but should be offloaded from your development teams.  Many vendors deliver these capabilities and again they can be purchased for pennies per user.

Elegant Integration

When looking to stand up a new capability, the quickest way to deliver is to wire together other capabilities.  In the past we would use Service Oriented Architecture to wire up capabilities. But today, we can use any number of vendors that deliver codeless integrations with any number of SaaS vendors.  These capabilities run at a scale and a distribution that cannot easily be matched with your own teams.  These integrations can simply bring together the capabilities that your offering needs, without the overhead or headache of writing yet more software.

At the end of the day, there are so many ways to deliver software without having to write any code.  Elegantly using integration tools and finding SaaS vendors that help you get to market faster, while you concentrate on what makes you unique and different, will allow you to meet the needs of users more quickly and efficiently than was the case a few years ago.

1 Tip:

1. The software you create should further your competitive agenda, and if it is not key to fostering your differentiation you should acquire it from somewhere else.

Thank You

Jim ‘The Designatic’ Tyrrell

Subscribe now

Customer

Your customer, as a user of your offering, will encounter challenges along the way.  These challenges will create Friction, Toil, and Invisible work for the end users.  As technical creators and/or founders, the issues and troubles you seamlessly power through, are exactly the kind of issues that will stop your users, cold, in their tracks.  For example, when the next best action isn’t obvious in the User Interface or you repeatedly ask a user to do something that could be automated, you create challenges for them.  When you ask your users to learn something new in your offering, and you don’t account for the resultant invisible work, you are making life for your users a lot harder than it needs to be.

Share

Friction

Friction often takes on 3 forms: Emotional, Cognitive, and Interaction as defined by Sachin Rekhi in a 2017 Medium article[1].  Your users are bringing all of themselves in their best and worst ways to their interaction with you.  Being human is very hard, and getting harder every day.  We often forget  that the User Interface (UI) we are delivering is just one of the 100s, or maybe 1000s that a user will interact with on any given day.  The user isn’t intimately familiar with your offering.  They haven’t lived it the way you have.    You are hopefully in a good emotional place while developing and creating it, but the same can not always be said for your users when they are using it.  They may not have the patience or smarts that you have, and they are certainly less familiar with all of your product’s capabilities than you are.  You can’t fault them for this.  Instead, you need to put yourself in their shoes, through research and observation. If you observe and understand the friction your users encounter within your offering, you can begin to design around or remove that friction. 

Toil

Any number of items can fall into toil.  Forcing the resetting of passwords on a fairly regular schedule is an easy one to eliminate and research has shown it actually makes your systems less secure.  Having users use swivel chair integration by requiring cutting and pasting between different systems or browsers, is yet another form of toil.  Having people repeat things like re-entering mailing addresses, credit cards, or other information is toil that should be eliminated.  If you watch your users for any length of time you will see patterns of repetition between sessions that you should seek to eliminate.    

Invisible Work

This is sometimes the hardest to uncover because it is insidious and hidden by definition.  It manifests itself when you do, what you think is a simple software update, but requires the reskilling or retraining of your end users to use the new capability.  And if you think about it, this also creates work for your documentation, support, and other teams to keep up with the changes.  Long setup or signup processes also create invisible work for end users and their support or admin staff.  Another one is not giving the next best action or allowing for self-service in/from your application to resolve issues.  The last one I’ll mention is the time it takes to get support to resolve an issue.  This can just be the time lag in tickets, but could also be the length of time it takes to answer a phone call or chat message.  The customer waiting around for this resolution is another form of invisible work.

To combat all 3 of these, Friction, Toil, and Invisible work, one simple tip is all it takes.

1 Tip:

1. Watch and interview your user/s, you will find tons of greenspace to innovate and minimize Friction, Toil, and Invisible work in your offering.

Thank You

Jim ‘The Designatic’ Tyrrell

[1]

https://medium.com/@sachinrekhi/the-hierarchy-of-user-friction-e99113b77d78 

Subscribe now

Team Challenges

As a technical leader, the decisions you make will have a tremendous impact on the Friction, Toil, and Invisible work that your team has to live with as they go about their day-to-day work lives.  These terms are all somewhat interconnected, and all relate to the drudgery of system administration and programming that has infected every development organization I have ever been a part of.  We often spend too little time auditing our rituals.  Instead, we do things the way we’ve always done them.  As our new activities start we have no methods to green light them, nor do we have processes to end of life them when they no longer serve a purpose.  I am amazed that well-intended development organizations haven’t culled their systems to empower teams to be as efficient as possible with their most precious resource, time.  Instead, developers waste time with duplicative apps, like multiple chat systems or bug tracking systems.  Combating Friction, Toil, and Invisible work has to be top of mind for every leader.  Let’s break down some of the common items I’ve seen across organizations.

Friction

Friction often takes on 3 forms: Emotional, Cognitive, and Interaction as defined by Sachin Rekhi in a 2017 Medium article[1].  Emotional friction is the feelings your users have around developing your product or service.  Often developers will use up a lot of cognition or brainpower when developing your offering. This leaves little energy for thinking about the end user.  And ultimately can lead to a product that end users aren’t happy with.  How many times have you heard your developers wish they had smarter users?  Users aren’t going to get smarter, but developers can be given a more streamlined and productive environment in order to free up some cognitive space.   Cognitive friction is overloading the brain beyond its capacity, and in modern software development, we often expect developers to have more capability than is possible.  In all cases, our brains have not evolved at the pace of technology, and yet we expect engineers to keep up with this acceleration of technology change.  Being vigilant against new technology being added to your stack for the sake of technology, is an easy win.  Finally, Interaction friction has to do with the tools you provide for your teams. Is access hidden behind a ticketing system, or do you prevent teams from accessing the systems they need to complete a job?  Do you provide the best tools for the jobs at hand?  Making sure your developers experience as little friction as possible is a key to efficiency.

Toil

How many processes do you have that are burdensome to your users?  In other words, are your deployments entirely manual and fraught with human-injected errors, consisting of significant hand jamming of configuration files?  Have you made it easy to stand up local copies of development environments and the ability to set up a local copy that replicates the reality of a production system?  Does testing occur automatically with each build, giving you the benefits and sanity that a recent update has not broken or regressed anything?  Have you documented enough to ensure that others make changes to the system and understand your intent?  Finally, are you willing to have a great naming convention that evolves with your system changes,  so that wayfinding around your systems and deployment is easy. 

Invisible Work

This is the work that isn’t easily tracked but is impacted and driven by many of the decisions made above.   

Some examples of invisible work:

• Mandating that passwords are updated every 30 days, and have to have numbers, letters, and special characters for access to internal systems.  Much better to get with 2-factor and allow your humans to be human. 

• Requiring server installation and setup be done by hand, instead of having automation available to quickly stand up infrastructure for you.

• Not using any number of SaaS services to give you baseline capabilities that allow you to quickly deliver. 
  Your custom development decisions should be driven entirely by what you are innovating in, and what can not be purchased off the shelf.

5 Tips:

1. Be deliberate with the Emotional, Cognitive, and Interaction Friction you inject into your team and the team’s processes.

2. Minimize the toil that your teams encounter and audit anything that gets created to be sure it’s absolutely necessary..

3. Track all the work you are injecting into your teams and have a process for managing the amount of invisible work they do..

Thank You

Jim ‘The Designatic’ Tyrrell

[1]

https://medium.com/@sachinrekhi/the-hierarchy-of-user-friction-e99113b77d78

Application as a Browser

Lately, I’ve been noticing a few different mobile applications doing one thing very poorly.  For all intents and purposes, each application is delivered as a web application that expects, or rather, requires an always-on connection to a server.  But it gets worse; the application deployed is another implementation of the website, with another codebase and in many cases different features and capabilities.  The differences in experiences fostered by two different code bases, not to mention the expense of twice the testing, twice the development (or is it three times, if you also have a separate Android Application), are massive to your organization.  How do you keep all user experiences in sync?  How do you ensure your backend data stores are not being written with bad or corrupted data?  As a human-centered technologist and consumer of these applications, it just horrifies me at all levels of my being and shows a failure of leadership.

Leadership Failure

Show me a software delivery organization and I will show you one that is behind the curve on delivering the capabilities needed for the business.  I am not sure how any business at any scale can afford to have duplicates of any part of the stack they are using.  It is certainly possible to have multiple authentication providers, but why would you?  A fast-moving user will always be confused when their password change took effect on the mobile app, but not yet on the website.  Or in the case of United Airlines, different password lengths are supported, depending on whether you updated on the mobile application or the website.  Further, scheduling two releases or even three to coincide with each other is a structural scheduling failure of epic proportions.  The amount of time you will wait for laggards to catch up with the leader ready to ship, compounds with every release and over time adds up to months, or possibly years of lost productivity and huge opportunity costs.  When you think of the expense of development teams and require at least 3 teams to be in sync for every update, the employee costs are staggering.  At the end of the day please have just one code base for your end users, no business can afford to have duplicative development teams.

Always On, The Silent Killer

Mobile Applications are by definition mobile, this is a benefit and curse.  It is a benefit because this application is with you at every point of your daily journey.  Where this falls down for me, on far too many occasions, is not being on Wi-Fi.  Thankfully, Apple allows you to turn off internet access over cellular for applications.  Did you know that many applications will silently fail and not let you know that no route to the server was found, or worse, they give you a silent error with the application seemingly not working at all?  MyFitnessPal I’m looking at you.  I have experienced this countless times and with every poor experience I wonder who was developing and testing the application, and how could the developers have such a lack of vision to understand a core way in which users will be using the offering.  Further, not testing this use case and giving good error messages is an outcome worse than just about any I can think of.  If your testing does not account for a no-network modality, you probably should rethink your testing strategy.

Disconnected Design, It is Inevitable

Your users will inevitably use your application while not connected to the internet.  This lack of connectivity could be induced by a failure of your cloud provider, the network, or even when you need to do some maintenance.  While there are many ways to ensure that an application always has something to talk to in the backend, these redundancies cost extra and create a lot of headaches.  In the end, you will always have a bit of downtime, unless you work really really hard to solve all possible outages.  It would be much better for your back-end teams and developers, to assume there are times when your back-end services will not be available, and you should code your mobile applications to deal with this reality.  I am especially thinking of applications that provide meditations, tracking, or to-do list capabilities.  Why in the world can I not utilize these applications without a connection, and why doesn’t the application just sync when the network is restored?  If applications were available regardless of connectivity, the benefit to the user is seeing nearly instantaneous responses to all actions, a big win for the end user.  If you do have a browser and application in use, you will have to do some work to indicate the information is not yet saved centrally yet, but that is a small UX detail that can be easily worked out.

5 Suggestions to help:

1. Do not duplicate or triplicate development teams and efforts, you can’t afford it, and your customers deserve a consistent experience.

2. Do not have different systems of record that depend on the source of your users, mobile, browser-based,  or call centers.

3. Don’t expect your users to have an always-on connection to the internet; and test and design for that possibility.

4. Don’t ever give your users an experience with a white screen of death or empty results without some indication that something has gone amiss.

5. Do provide a degraded but useful experience for your end users when they are without a network connection and seamlessly sync the back-end when connectivity is restored.

Thank You

Jim ‘The Designatic’ Tyrrell

Beta to Production

From the first line of code you deploy, until the time you deliver your MLLP (Minimum Lovable and Launchable Product), you have some hard choices to make.  For those of us that have been around software a long time, a typical path to delivery might look like this: local development on developer laptops, then some formal testing, followed by shared integration for evaluation, and finally production.  Each stage is a standalone environment with its own obstacles, costs, and headaches that can slow things down.  And, if you ask 10 architects how to deliver an MLLP,  you will get 11 answers as to the right way to do it.  Balancing the need for speed against uptime is a challenging problem, that is not unlike the old axiom, “You can have it fast, cheap or good.  Pick two.”  In this cloud world, and with current consumer expectations, the idea that SaaS software has the time to go through all these stage gates is challenged at best; and morale and idea killing at worst.  With that said, what is recommended?

Developer to Production

A typical software deployment pipeline, when starting out, will go something like this. Developers will use Git to version control their software.  They will have some unit and integration tests created, with a good balance of what is covered.  Going for complete coverage for simple CRUD (Create, Read, Update, and Delete) operations is probably a waste of time, but covering the business logic, and areas where the state is manipulated, is a good idea.  Zero test coverage is a bad idea, and 100% test coverage is untenable.  You will have to figure out what is required to strike a balance.  While you are in the pre-launch mode, you can take these code changes, that were developed using a Git branch per capability, and deploy them right to the production instances.  This gives you maximum agility but probably leads to some things breaking.  Move fast and try things, right!!  Of course, before you deploy you want to review what has been changed, what you expect should work, and ensure the test suite is running well.  While in this fast-moving mode, you need to ensure that great documentation is happening around your server configurations.  You want to implement solid backup and recovery processes, including taking these offsite, and ensuring backups are not destroying the older backups.  If you do all of this, you will set a great foundation for what comes next.

As you Launch

There are two things that you need to consider when you start to allow humans outside of your teams, to use your software.  The first, have a test environment that replicates production as closely as possible.  In other words, use NGINX or Apache, pick just one for your stack, and commit to it. Also, avoid the sprawl of many languages and/or technologies.  For example stick with the database you are using in production, just pick one, MySQL, Oracle, MongoDB, etc.  Note that they can be much smaller in the test environment.  Be sure your URLs, folders, configuration files, and all artifacts have a nice ontology and naming convention.  For example, I like test.api.domain.com and api.domain.com to distinguish between my test and production environments for domain names, configuration files, and folders.  Unspecific words like default or configuration should be avoided at all costs.  Wayfinding, and knowing where you are, while you are making changes, is critical for uptime and keeping your sanity as you make changes.  Having a robust test environment as described for trying out infrastructure changes is critical to ensure simple configuration changes do not take down production.  What I have described might be called integration.  At Lyft, they simulate a significant load on the sub-systems to avoid having to deploy a full copy of production.  A four-part series starts at this link, check it out. [1]

Launch Darkly  

The second item to consider when you are going live, is how to test features before your customers can look at them.  Launch Darkly is the premier SaaS vendor that allows you to simply enable capabilities in your SaaS per groups or specific users.  Hiding capabilities from all users, and only giving them to specific users in production is a way to manage the agility and velocity of your team, while also protecting the majority of end users from broken features or features that are not fully vetted.  Give your customers new capabilities, on a set schedule, instead of a big-bang release every quarter, which allows your teams to sleep at night and live up to a schedule that you set.  If you think about Facebook, LinkedIn, or Amazon, they are always running experiments and delivering incremental small improvements all of the time.  Give your users a break by skipping big bang quarterly releases that require a ton of training and reskilling.  Instead, staging and delivering small improvements can improve everyone's quality of life incrementally, both for your customers and your teams.

Beta Trials

Once you have all of this working, and as you scale your organization, you can think about having a beta site, where you let your best customers inside the circle and give them special access to in-process feature creation and development.  These trial users would use the production database, with the latest and greatest features and capabilities.  This kind of development and deployment is not for the faint of heart but does have the potential to create devoted users that love your offer.  Don’t give it away for free.  Instead make it a source of revenue and point of engagement for your Success team. 

Maintaining agility and velocity at all development stages of your SaaS is critical, for customer happiness, but also for developer sanity.

Thank You

Jim ‘The Designatic’ Tyrrell

[1] https://eng.lyft.com/scaling-productivity-on-microservices-at-lyft-part-1-a2f5d9a77813

Share