This post
is from a set of slides I did in a presentation to a group of product managers.
The title of the talk was "working effectively with developers"; and
the general theme was to explain development terms such as "technical
debt" and "re-factoring".
Once we
started talking out what these terms meant and how they fit into a development
process; a larger picture of what software product development actually 'is'
started to emerge. So, to break this very large subject down into a
manageable presentation I used the tactic of investigative journalism, and
focused on how the 'who', 'why', 'what', 'where', 'when' and 'how' of
developing products.
This is
from a developer point of view, but drawn from experience of being both a
developer and a product manager. When starting a software company from
scratch, you really need to perform the duties of these roles at the same time,
and you realize that the goals of both of these roles are the same:
Observation: At the end of the day the
main goal is to solve a user’s problem with your technology; and they will pay
you for it. With that money you eat, party, and continue the cycle again.
What is product management?
When
talking to many of my product manager and development colleagues: one theme
started to emerge pretty quickly. The definition of what "it is" was
different with every conversation, and when referencing job descriptions that
were titled "Product Manager" the roles and responsibilities outlined
seemed to diverge just as much.
This
role, which didn't really exist 20 years ago, is still finding its own
definition. That definition is different in every group (company/team)
producing software. Now, I see it as a catch-all to manage:
- a Product (what?)
- a Customer (who and why?)
- a Process to make it (how)
- the Schedule to deliver a
solution (when)
- a Team to make the solution
(who again? yikes)
This
sounds like everything! So, to do everything it might be a good idea to
separate the Roles and Responsibilities to understand what gets done, by who,
and when. Be sure to have an in-depth conversation to outline these
responsibilities (and expectations) when taking on a Product manager job.
The Product Developer
From the developer’s
point of view, there has been an equal amount of change in what a 'developer'
is. In the most fundamental view, a technology developer has to perform 3 basic
functions. There needs to be a design of a system, the implementation of
a system, and the validation of the systems function and
utility.
In isolation,
with well defined design, this is possible in many technologies. Buildings are
designed with blueprints, and built with construction methods, and validated
with engineering. That works in civil technology (buildings, cars, trains), but
for software engineering the methods are different.
Observation: Skill vary tremendously when
talking about one person doing this, and software lacks formal education and
certification on what it means to be an 'architect', 'engineer' or builder
(programmer). This hasn't been standardized; so for a non-technical person to
hire a 'developer' its a very murky understanding of what a person is capable
of.
So, lets investigate....
The order
of priority on the 'who', 'why', 'what', 'where', 'when' and 'how' matters
greatly, but it all has to get done. Things differ in the type of company it
is. Is it product driven or project driven? If you are selling hours as a
consultant the accounting of hours and the estimation of effort take on greater
importance. If this is a product then the customer relationship and Domain
expertise take on a greater importance than the schedule. It really depends on
what you are getting paid for.
In the view
of the product manager, I believe the order of priority should be “Who”, then “Why”
and the rest in random order. If those first two are taken care of, many parts
of the what, how and when fall into place. This is probably an over-simplification,
but I really want to state the importance of the Who and Why in the realm of
the product managers priorities.
Why we build products
This is
fundamentally the main purpose of product management. Understanding why a
customer needs what you are building. They need to solve their problem, and in
using your product they want to solve it in a more effective way then they are
currently doing it.
How to do
this effectively? Understand the Customer and their Domain, understand what their
job is, what is the actual outputs are and why some outputs are more important
than others. This Domain modelling is extremely important in a product driven
company.
Stakeholder
are everywhere! The customer, their boss, your boss, your team-mates and their
boss. Everyone has an interest that all this goes well. The priority of who
gets attention can get lost in a busy day, but in the end, the customer should
win all debates
Observation:
In a
software company, you will work with smart people, and those people will have opinions
(hopefully). This is a good problem to have, but it can lead to ‘analysis paralysis’
in figuring out what to do next. Use the Customers point of view as a unifying
force. Create your personas and outline their problems, name them and use them to
put light on what’s important. We all have opinions, but the customers opinion actually
pays the bills.
What we are building: a technology
You can
build buildings, cars or software, but the same fundamentals of Utility,
Structure and Beauty apply to successful pieces of technology. It has to work,
it has to solve a problem, and even better it has to feel good doing it.
- Functionality – solves problems, or doesn’t
- Structure – works great, or falls apart
- Usability – feels great to use, or not
For architecture nerds out there, this is the fundamental pattern of architecture known as the Vitruvian Triad. It holds up as a valuable pattern even if it was defined 2000 years ago.
For Software, we run into a bit of an issue here. Software isn’t physical, it needs hardware, and the user only sees about 10-15% of the technology. I call this the ‘Iceberg effect’; since the user only interacts with the UI and doesn’t (and shouldn’t) be exposed to the inner workings of what is making diagram change when a button is clicked.
‘Tech Debt’
So, the
term ‘tech-debt’ seems to strike fear in the business crowd, and for this
developer its hard to understand why. Businesses (especially start-ups) don’t
seem afraid of debt at all, and sometimes leverage the entire perceived value
of the company for funding.
What is
the current state of your technical balance sheet? You have assets if users are
using features in your system, and you may have taken on debt to create them.
How does
tech debt happen? Feature complexity is fun and easy to make when you ignore
the costs. Same way that its fun to make dinner and not do the dishes
- Keep a Source of truth on assets (tested requirements), and understand the debt incurred to make them.
- Pay off a little debt each release. Improve the Usability, Performance, Security, Observe-ability, Portability and Maintainability of your system.
Observation: Debt can be very useful, but it
needs to be managed; or the complexity of managing debt will overwhelm you.
How to build products
Process
and culture have the greatest effect on product quality. its a people issue. Ad-hoc
process makes ad-hoc products and the user can tell.
Earlier
on the roles to build software were somewhat defined: The Business Analyst
modeled the domain of the customer, an Architect created a model to reflect
that Domain, and Engineers and Programmers implemented that model.
This was
seen as a 'waterfall process' and while that worked for well defined and small
products, things really fell apart in the larger products. Why? its because the
understanding of what is being built changes over time, and that directly
relates to the requirements of the system being built. Once the requirements
become fuzzy, or not well understood, its really up to the mind of the implementer
to get it 'right'.
Observation: This phenomenon has been
described as 'changing requirements' but the reality is that the requirements
of what is needed don't really change; you and your teams understanding of
what the requirements change over time. In the language of developers: you re-factor
your definition of the requirements as you learn more about them.
How about
that mock-up?
From my
angle, a detailed mock-up is helpful, but you seem to want a lot more. A UI
mock-up is like defining what a room looks like when you want a house. What
really matters is the experience using it; and I see this getting better quickly
with design process and (CX, UX)
Observation: Define
Done to have a chance at finishing (or actually estimating work)
Good
requirements force simplifying through testing. You need requirements to
define, build and test and software
Releasing
Observation: You will learn the most about
your product, team and process when you release.
Plan and
be strategic all you like about the future; what you have today has the
greatest effect on your success.
- version everything, its the last version not the date that matters
- shipping to customer isn't done. reviewing and cleaning up is done.
- release through the company to get to the customer. This allows collective knowledge to be set to the new reality with every release
Build
planned work, and respond to requests on different boards. Use a feature driven
process to build new features, this is something you can plan. Don’t bother
trying to plan and estimate bugs, just use a different mechanism to deal with
it.
Who is building the product?
Try to
use small teams for features and working groups for cross-functional items. The
same group of people can work on many different teams. They do anyway, so just
put some structure around it
- Meet and measure on outcomes, and only measure things that can’t talk. People talk, so talk to them and don’t try to apply metrics to their output. This builds communication, collaboration, trust, and respect.
If you are injecting work into your sprint, then there is very little value to any planning and estimation.
Kanban is great for support work and random requests. FDD, XP when used with Scrum can work for feature development (if emphasis is on requirements, not estimations)
Wrap it Up!
- Priority is Who/Why
- Build around customer problems
- Customer development never stops, close the loop with customer validation.
- Domain knowledge is more important than technical knowledge
- What
- Useful, Functional, and Usable will win
- Beware of the ‘iceburg’ effect; it all has to get to get done.
- Continually remove complexity, don't allow debt to overwhelm you. Complexity of your own creation is the real enemy.
- When
- Define what ‘done’ is to have any chance at correct estimates
- Done is finishing the dishes, not just serving dinner.
- Less is more, slower is faster
- How
- Close Loops. If the issue originated with a customer, it's not done until the customer is happy with the solution.
- Realistic requirements, not just UI mock-ups
- Version everything and make smaller maps into the future
- Involve Developers early and over communicate, as collective ownership really works.
