Soft Advice for Software Development.
A couple of months ago, The team was invited by the Universidad Autónoma de Querétaro to give a couple of talks to Software Engineering Majors. Yamil, our lead developer talked about infrastructure automation, while I talked about Soft Advice for Software Development.
I am not an engineer by formation nor trade. My experience in product management comes from experience. Some product successes and some other flops. In this talk, I mixed and matched several techniques from Agile Development and Marty Cagan’s Roadmapping concepts.
The goal for this talk was to share some of the techniques and how we do alignment at Cordage.
Should you even build software?
Yes. That is the first question. Do you even need to build software any more in a no-code, open source, and vertical-specific SaaS world? I would recommend this post by Intercom.
Every year thousands of people want to build software for generic or supporting needs like billing. This undifferentiated heavy-lifting will not provide value to the organization; it may even represent a cost increase if you consider maintenance and support costs.
Organizations and companies need to be aware of their core-competences and what makes them stand out in the market. If these are unique (and only if) and will lead to market differentiation, software should be built.
Value and Alignment in Software
The main reason we are building software is to provide value and solve a problem. A valuable application is one that solves a problem in the right way, for the right people, at the right cost, and with the right perceived value.
Why is alignment necessary? I am sure you’ve heard the story of the blind men and the elephant. Long story short, a group of people are asked to conceptualize what an elephant is based on their touch –and limited experience. All of the descriptions are different, but they are all partially true.
I believe everyone in an organization wants the group to succeed. Nevertheless, just like the elephant, we may not know what success is. For engineers success may be an efficient code-base; but, for finance, it may mean profitability. At times, these “Successes” may counter one another.
As organizations grow more complex, it becomes tougher to explain what we are trying to achieve with our software.
A simple example could be a tech-blog. The monetization department wants to make more money. The content department wants to break stories. The engineering department wants up-time. All of the departments know how to measure their department’s success, but they have different definitions of organizational success looks like.
Software organizations need a compelling vision. A vision of a “photograph” of the future. It states what the company wants to become. This description provides a direction of what needs to be done in order to achieve success in the future.
Value creation and delivery needs shared understanding and organizational alignment. Before we even decide how we will measure success, we need to define what is “success” to the company. One our vision and mission have been established, we have a guide towards saying “NO”.
Simply put, You can’t boil the ocean.
Saying NO, Matters
If your mission is to train the best athletes and your vision is to turn your city into an Olympic Sports super-power, You are saying no to Football (Not an Olympic Sport) and to casual gym-goers. Decisions made at the top will guide decision making and your resource allocation.
E.g. Cordage’s mission is to create a world with more valuable and reliable products and services.
From Abstract to Concrete
The role of a product manager is to transform abstract concepts into tangible artifacts. Our corporate ideology will guide our product, market, themes, values, and principles. If your mission is going to the beach, how will you get there?
Vision and mission are the least mutable ideological element in our product development practice. Our corporate values are our true north and we must live these values accordingly. As we approach execution, we become flexible and respond to changing conditions. Like Scott Belsky says: “Be mission-driven, but medium agnostic.”
Based on Marty Cagan’s books, I’ve come up with a visualization that describes how vision changes over time, how it relates to product execution and organizational structure. For a more detailed and execution based diagram, check John Cutler’s work
In this diagram, every bar is the duration of an idea throughout time. At the top, we have the most abstract of ideas, and at the bottom the most concrete.
For example:
“Surf a Large Wave”
“Picking which beach to go to”
“Budget our trip to the Beach”
“Buy Tickets”/ “Book Hotel” / “Ask for a Vacation”
In our day to day, we can change the scope of our sprint, change our priorities and respond to changing market conditions and customer requests. However, we must be sure that whatever decision we make is aligned with our Road-map, Product Vision and Corporate vision.
Principles and values trickle from the top. It is important for the whole team to understand the what and why of our work. It is critical to understand that in the long-term Corporate Vision and Mission will also change. Market conditions and life will change what we are trying to achieve.
Our alignment chart follows a traditional organization chart. At the top, leadership sets the true-north for the whole organization. These values trickle-down towards managers who define the product vision. All of these trickles down until we reach the individual contributor. The individual contributor is empowered to make decisions based on the scope of work and what the whole organization is trying to achieve.
Glossary:
Product Vision
The product vision is the overarching goal you are aiming for, the reason for creating the product. It provides a continued purpose in an ever-changing world, acts as the product’s true north, provides motivation when the going gets tough, and facilitates effective collaboration.
I.E. Our product vision is to be the hub for Quality 4.0
Product Themes
According to Jared Spool, Themes are a promise to solve a problem without the commitment of delivering a certain feature. Specific product features need to have alignment to the themes.
Ie. For example, Cordage is Enterprise Ready.
Product Principles
Product principles work as a manifesto and speak to the nature of the product. Principles guide the decision making process and help the team align to what is expected. Acceptable behavior for the team. What is acceptable and what isn’t. It is a way to empower teams to make decisions or their own.
Ie. At Cordage, one of our product principles is: Think big, execute small.
Roadmap
The direction we are headed. Roadmaps are the short term vision, where we are headed. They are limited in scope and present an ideological approach.
Ie. We have Cordage’s V1 release in our Q4 Roadmap.
Release Plan
The what is going to be delivered and when. A Release plan is made up of a series of Sprints. Roadmaps and Release Plans are confused quite often. A Roadmap is the “Why”, A Release Plan is the What.
Ie. Release Plan Q4. Create Document Approval Workflow. Edit Document Approval Workflow.
Outcomes vs Outputs
Outputs are the results we get, outcomes are the end result.
If you buy an engagement ring, your output is an engagement ring. The outcome is a happy moment and a new life with your significant other.
Additional Notes:
I went over additional topics like Kano Model, The RICE Framework, the Impact Effort Matrix. User Story Mapping and the likes. This is a simple way we describe what we do, how we do it and why we like doing it.
We are Cordage. A mission-driven but value agnostic company building the Hub for Quality 4.0. Our mission is to help build a world with safer, more valuable and more reliable products, interactions and services. We are convinced that we can achieve this through quality and technology.
