Tuesday, December 10, 2019

The W5 of developing software products


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
Observation: Functionality and a little Usability can work even if structure isn’t great. People love Ferraris even though they break down, and people loved Twitter when they kept getting the 'fail whale' screen. Despite the structural issues, the functionality and usability was there.



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
  1. Keep a Source of truth on assets (tested requirements), and understand the debt incurred to make them.
  2.  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.


  • Observation: Separate support requests and new feature development



  • 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!

    1. Priority is Who/Why
      1. Build around customer problems
      2. Customer development never stops, close the loop with customer validation.
      3. Domain knowledge is more important than technical knowledge
    2. What
      1. Useful, Functional, and Usable will win
      2. Beware of the ‘iceburg’ effect; it all has to get to get done.
      3. Continually remove complexity, don't allow debt to overwhelm you. Complexity of your own creation is the real enemy.
    3. When
      1. Define what ‘done’ is to have any chance at correct estimates
        1.  Done is finishing the dishes, not just serving dinner.
      2. Less is more, slower is faster
    4. How
      1. Close Loops. If the issue originated with a customer, it's not done until the customer is happy with the solution.
      2. Realistic requirements, not just UI mock-ups
      3. Version everything and make smaller maps into the future
      4. Involve Developers early and over communicate, as collective ownership really works.



    No comments:

    Post a Comment