Three (self-made) tools for Product Management

Publicado por · Deja un comentario 

In a previous life I had the chance of starting from scratch the company’s Software Product Management department. I was able to define the processes and choose the tools to manage them. Although there are great pieces of software out there than can be extremely helpful, it is also certain that they come with a cost.

I would like to share here three of these self-made tools. I do not mean to be exhaustive and cover the whole product lifecycle, but to illustrate that you can do great things with as little resources as a spreadsheet.

Product portfolio risk analysis

In order to balance the different product development initiatives and help top management decide which ones to pursue, I adapted the Risk Matrix of George Day (originally published in the Harvard Business Review). In this matrix, market uncertainty is assessed in the horizontal axis, while product and technology risks are measured in the vertical axis. The initiatives to be evaluated are charted and fall into empirical risk regions that evaluate the chances of failure.

In this case the portfolio is quite balanced with a low-risk Product 1, two incremental developments (Products 2 & 5), a risky Product 4 and a highly innovative Product 3. In a single chart the characterization of each product in the portfolio can be assessed, as well as the risks that demand management attention.

Product portfolio lifecyle analysis

This tool allows seeing where in the lifecycle stage a given product is, if and when to expect a new release, and the product versioning policy. There are vertical swimlanes for each stage of the product lifecyle (in my case these were Proposal, Definition, Development, and Launch, but they could be adapted to any other set of stages, for instance to include Retirement). Each version of the product is then located in its corresponding swimlane, and even moved inside it to reflect stage maturity. From the previous chart a synthetic risk measure can be calculated and is used to locate the products in the vertical axis.

In the example, Product 2 is in active development, a new version of Product 1 has been recently launched and the following one is being defined, Product 3 is about to begin the development of a pilot as the phase 1 is nearing maturity, and Products 4 & 5 are awaiting definition – or a sponsor.

Product portfolio roadmap

The final tool is a simple Gantt diagram to show product releases over time. Alongside with a feature list by release, it is a powerful way to define product portfolio roadmaps.

Here we can see that Product 2 has a faster release cycle than Product 1. Also, development for Products 3 & 4 is frozen, probably because they are waiting for a sponsor.

Conclusion

I hope these three tools are useful for a starting Product Manager. Very simple resources and a little bit of creativity can go a long way to support your Product Management process, and you just have to apply them consistently to help you succeed.

Three insights

Publicado por · Deja un comentario 

I would like to share three insights that have lately become a kind of guiding principles for my work on product/project management on analytics:

  • Make it work, make it right, make it fast
  • Separation of compute and storage
  • Agile is not the same as fast

Make it work, make it right, make it fast

I first knew about this principle in a guide to data science job interviewing. Later on I read about its many interpretations in the mother of all wikis. The meaning for me is as follows.

Firstly write the skeleton of the algorithm, program or thing you are trying to build. Just the basics, with no real functionality, just to ensure that it compiles, runs or executes. Then write the logic in a simple, naive way, but that yields the correct answer. Finally try to improve on speed, space or any other critical performance parameter.

Apart from being in line with the avoidance of premature optimization, this way of operating helps in reducing uncertainty, building confidence, and showing early results.

Separation of compute and storage

Recently I read an ebook titled Creating a Data-Driven Enterprise with DataOps, and this principle appeared in a chapter about Cloud Architecture. Although initially it seemed counterintuitive, the more thought I poured into the concept the more sense it made.

In the cloud, storage and processing are decoupled, and the former is cheap and permanent while the latter is ephemeral and expensive. Compare this to on-premise analytics where both are coupled, permanent and limited.

The impact that this principle has had on me has been profound, even considering how recently I have discovered it, and it has helped me design, implement, and communicate analytical architectures in a convincing manner.

Agile does not mean faster

I have recently discovered the deeply rooted misconception that being agile means giving up on preparation and alignment of stakeholders, and just hoping that every problem will sort out itself during the process of development. This is utterly wrong.

The Agile Manifesto does not mention fast development a single time. Moreover, there are other references that explicitly state that agile does not equate to fast.

In my experience, an agile framework introduces routines and discussion environments where new requirements and feedback from users can be introduced in the scope of the project or product, faults can be detected earlier, and a valid outcome is ready at the end of a sprint. This, however, comes with an associated cost in time and coordination. Agile methods will make reacting to changes easier, but they will not replace preparation before starting a project, and they are not, by any means, an excuse to cherry-picking features to boost in the middle of a sprint for the sake of showing them off in a committee.

In the long run, being agile will mean being faster. This will be caused by hitting the mark more frequently, not by making individual projects faster. As a matter of fact, less projects are expected to be run with a higher level of resources. At the individual project level this is clearly slower and more expensive, but at the project portfolio or the product levels it completely makes sense, if the required time for the methodology to provide results is allowed.

Conclusion

These three insights have become guiding principles in my endeavors in software development, and they help me make decisions and structure my work. I am always open to improve and learn from others, so… what are your guiding principles?

Un año en Aqualogy Business Software

Publicado por · Deja un comentario 

Rápido pasa el tiempo, y ya llevo un año en Aqualogy Business Software. Es una etapa de muchos cambios; veremos lo que está por venir.

My toolbox

Publicado por · Deja un comentario 

Just looking at my work laptop I can see that my toolbox is quite large. It includes, in no particular order:

  • Microsoft Office
  • Open Office
  • eclipse
  • Java
  • Python
  • Apache Tomcat
  • Delphi
  • Oracle 11g client
  • MySQL
  • H2
  • Visual Studio 2005
  • SQL Power Suite
  • SQuirreL
  • SQL Power Architect
  • PL/SQL Developer
  • Quantum GIS
  • R
  • Matlab
  • TortoiseSVN
  • Unlocker
  • Skype
  • join.me
  • Team Viewer
  • Adobe Captivate
  • Adobe Reader
  • DWG True View
  • Cisco VPN Client
  • Enterprise Architect
  • paint.NET
  • SyncToy
  • Sublime Text
  • Notepad++
  • Evolus Pencil
  • Resource Hacker
  • FileZilla
  • HDFView
  • Help&Manual
  • InnoSetup

I’ve used all of them during the last year. So much for specialization!

De vuelta

Publicado por · Deja un comentario 

Después de recorrer más de 2.800 kilómetros y haber estado desaparecidos durante quince días, hoy hemos vuelto a casa.

Hemos estado en la otra punta del país, en Galicia, haciendo una cura de sueño y comida que todos necesitábamos. Ha sido una desconexión total pero esencial para reencontrarnos y coger fuerzas para un periodo muy interesante que comienza ahora.

Ha valido la pena.