Modern Digital Products & #NoProjects
Dead or Alive Products
One of the very first things that Allan points out in his book(Project Myopia) is that there is a correlation between downloads and changes. Downloads are less critical than organic growth and customer satisfaction; however, there is an exciting connection. Dead software often has no downloads. Dead software means what? This usually means ZERO maintainers or ZERO changes. As an Architect, the first thing I look at an open-source library to use in any language like (Java, Scala, Go, or Rust) is to check is the library/framework is ALIVE. All these ideas bring us to two central questions, whats DEAD product means, what ALIVE product means?
* Done: Project is delivered, and no future projects are going on.
* No More Updates: Software stop changing, so no improvements, no new features.
* No More Maintainers: People stop working on the software since there is no project.
* No More PRs: Since people dont use it, no one wants to contribute.
* No More Investment: Since there are no users, there is no money to invest.
* No More Changes: ZERO changes, is the DEATH of the product.
* No More Downloads: No Download means no new users.
* No More Users: No more users means losing users until complete DEATH.
* Never Done: Always changing. No End.
* Always has updated: Never DONE.
* Has several maintainers / several companies/people involved: Since the product is alive, people want to be part of it.
* Has several PRs per week/month
* Has the constant investment
* Has changes in production every day
* Has Downloads everyday
* Has new users and retains user base
I think you get the picture. DEAD means-end othe line, no want wants DEAD. People won't relate to LIVE things. So products need to ALIVE and chaching all the time. So, in other words, even if you use PROJECTS, you dont want to projects END; you want one project that leads to another project and so on and on... This is so true, and it's completely wrong on the project mindset because projects have an END, and we dont want and END. Estimations have a relation on this matter, I recommend you read my latest post on #NoEstimates.
Project Lies and other incidents
It could be a Guns 'n Roses Album :D
So Projects need to have an END. Projects also require setup, project setup is super expensive, we need to do the following activities(not limited by and a super simple view):
* Marketing - Make sure people know your brand and what work with you. Product Branding and Engineering branding are completely different things.
* Hiring: Hiring is not cheap and not easy. You need to evaluate candidates in the sense of Cultural FIT, Attitudes, Skills, Apply Tech test, Review Tech knowledge, and is at least a 2-week long process per person.
* Train the team: not only in Agile, Lean, Devops principles but also in tech like Cloud, Languages, Frameworks, Databases, etc...
* Tune your team up: Make your teamwork well and deliver value constantly
When you managed to get all these parts done and working well, what you do? Well, you kill this project and start over. This makes sense for you? Projects also consider a success when you deliver on SCOPE, TIME, and BUDGET. First of all, this is very old, bridge-based, PMI concepts that dont apply to our current world anymore. I recommend you also read this post. Multiple projects also limit our pursuit of value. Because we are limited to think we need to finish one project before starting another, and if we consider the backlog flat, we could actually get all high priority items and work on the first and if we fail but do not use all money? Did we fail, or did we succeed? We fail considering traditional project definitions. Due to modern product discovery concepts, we actually succeed because we avoid wasting way more money on software that would not work for the customers.
Projects do not accept FAILURE. Projects assume you will deliver all the backlog you had. This definition is completed flawed within our modern product culture since Lean Startup said and done well - we dont know the product, the market, and the customer, and we need to DISCOVER. IF we need accept we dont know, how can we FIX the backlog? How can we tell we need these 10 exact features or user stories?
Debt as a Liability
Another killer insight Allan introduces on hos book is the issue with *Tech Debt* Term. I personally never liked the term tech debt; since we are building digital products, I prefer the term *Debt* since we can have product debt, UX debt, BA debt, etc...
However, Allan points out a much better concept. Liability. No one wants to have liability, thats non-negotiable. I wish this was the term, and every manager and product professional know this. Debt is often seen and a good thing in the business space, since every company has debt. However, liability is the view as no desired thing at all.
Liability VS DEBT is not only a different word. What matters most is change your mindset. I really recommend you read this post. Changing the mindset means, dont think only about feature and Output. Acknowledge that digital building products are hard, and we can't just pile up liabilities.
Inflate Expectations
This is another big issue most companies face today. Projects create false expectations. On paper, you might say a project cost U$ 500K year but, in reality, might cost 1M. Creating Gant charts and long projects and estimates only make us feel better but do not guarantee user adoption or drive better value. I believe it is the other way around, actually drives the worst performance and less value since we are focused and constrained about the things that do not matter.
Estimations are worst them expectations. Estimations are a kind of expectation. Once you set it up, it will be hard to change. Working with no expectations is hard. I deeply believe we need to Think BIG and have BOLD and audacious Dreams. However, I believe we need to Execute SMALL and very carefully.
Agile won't work for you if you dont change your expectations. Agile does not work if you don't ant accept true and hard things. Agile is like a mirror, you might not like what you will see. Expectations need to be managed and focused on making REAL customer impact not make a scheduled impact on a giant chart or 3-5 year roadmap.
Value Pursuit
Value Pursuit is what matters most. Know whats value is hard and tricky. Customer obsession, UX hard work are the only way we can get there. Experiment culture means: Allow failure to happen; with no failure, there is no innovation; with no innovation, there is no impressive customer impact. We need to acknowledge that building products is HARD and won't happen just because we build it.
If you dont DISCARD any user story making a discovery, it means that you are not making the discovery. Discovery means to play with ideas and experiment with what's the best and right impact on the customers. It's our view on the customer DEAD or ALIVE? Like I said before, software needs to be alive in order for us to have a great product. So how can the product be alive if our view on the customer is STATIC(dead)?
IF We know all the answers, why do we need UX? Could we just build and they will come? Well, the product industry and lean startup already showed us things do not work this way. Persuing value means accepting we dont know all the answers, and we will experiment and discover it. Following deadlines, blindly does not leave much space for discovery.
Continuous Improvement VS Crystalized Values
Continuous Improvement means:
* Listen to the customer(User - not only your business team)
* Listen to your engineering team
* Run regular Process/Team retrospectives
* Have 101 Sessions with everybody in your team
* Do RCAs(Root cause Analysis) and improve what is not working well
* Understand why bugs happen and avoid the happen for the same reason
* Understand the Variation and dependencies and try to manage it
* Do not kill all variation, or you will kill innovation
* Learn to see and eliminate waste(Lean)
* Improve and manage your flow, have limits (Kanban)
* Give visibility of all the improvements you are working all
All that does not work if you do not change your mindset. If you still are waiting for X features in the Y date given Z cost, no improvement will work for you. Because you are not focused on the value, you are focused on OUTPUT. Value cannot be crystallized, it needs to be ALIVE. So it's is in constant change.
Culture: The Elefant in the Room
Why it is so hard. Because your company is BIG and has lots of people who think in the same way. They reinforce themselves. So you are not facing one individual, you are facing something much stronger: Culture.
As an XP practitioner, I always believe in R2 Loops. The ide is old and comes older than XP actually in the 70s to be more precise. But Companies do not learn. R2 Loops means to change your strategy by changing your mental models and values. Otherwise, you are not really changing. Saying "I'm Agile" or "I',m Lean" do not make you Agile or Lean. Using practices without changing your thought process and beyond anything else, you "Expectations" means nothing.
This is the Way | A way Forward...
Like Yoda once said:
The only way is taught education. Education takes time, and it's not only done via training but via day by day hard work. Are your changing agents(agile Coachs, Managers, Leaders) promoting change day by day?
Are we measure the things that matter? Agile is all about the retrospective, but how many *Product Retrospectives* did you performed? How many product discussions you had after production? How many times did you talk with customer support? A product retrospective is different than a Team retrospective. We need to involve Customer Support, Sales, Product People(Discovery) and see numbers on USAGE and understand what is working and what is not working. Otherwise, we are just pilling features and hope our user base grows. Like Google SRE folks like to say: "Hope is not a Strategy".
Cheers,
Diego Pacheco
