Project SearchWing is aiming to build an autonomous drone. It’s leveraged to find castaways in the Mediterranean. The device is in use in Missions by Sea Watch.
Tag: organisation
-
Product Owner vs. Product Manager
Product Owner vs. Product Manager: Product Management is a challenging role and requires diverse skills. Large organisation often introduce a split between two similar, close roles – Product Ownership and Product Management. Both requires a large set of skills.
Jordan Bergtraum, The Product Mentor, a mentor at The Product Guy, leads a conversation on this split.
Source: The Product Guy.
-
Product Management vs Product Ownership
The organisation that I am part of introduced an overlaying Product Management department only fairly recently, less than a year ago. Early in the time it was exciting to see this role dedicated to market and customer perspective, but it raised questions over how this was different from Product Ownership from day one.
Over the course of the past year many discussions have been led and lot’s of articles have been led. This week Anthony Murphy shared his perspective and experiences on the Product Coalition. While my own experiences with this separated role have been predominantly positive, I tend to see the necessity to split responsibilities for larger organisations. The article is reflecting on why the Agile movement created the Product Owner in the way it did and how it was meant to abolish the Product Manager to start with.
A story of love, hate, oppression and triumph Source: The Collision of Product Management and Product Ownership
-
#SAP Leadership Announcement
Some huge changes to start the Weekend with at #SAP. As Executive Board Member and President of the Cloud Business Group Robert Enslin decided to step back from his role and pursue an external opportunity, Jennifer Morgan will succeed him as president of the Cloud Business Group (CBG). Adaire Fox-Martin will assume the role of president in the Global Customer Operations.
Morgan and Fox-Martin Expand ResponsibilitiesSource: SAP Leadership Announcement
-
Engineering Marketing
One important aspect of the implementation of product management roles and organisation, is the engineering partnership. The other day I found Julia Austins article on the topic that also touched the realistic options. To re-cap, these are either market oriented or engineering oriented. Either of these have their Pros and Cons.
My few thoughts on these two approaches:
Product Management driven Product development – While this indeed seems to be the more traditional approach, in which a “Product Manager” collects customer requirements. Nevertheless, it’s not necessarily a setup that is favourable for Waterfall development, nor is waterfall something favourable as as such for software development. It allows an organisation to maintain the customer focus through a dedicated person, that is incentivised differently than engineering.
Engineering driven Product development – This is an approach you can read a lot about from big tech companies recently. It requires a team that is well into the field the product shall serve, which often enough is not the case. In particular large and diversified companies will struggle to give find the right people at the right time, whereas smaller, growing companies can hire for the sharply defined purpose.
An compromise approach is sure the PM<>Engineering partnership to overcome the shortcoming, and the responsibility to maintain a customer focus is on the PMs shoulders
-
Innovation in Organisation
Digitalisierung ist als Schlagwort allgegenwärtig. Trotzdem bedeutet es nichts anderes als grundlegende, marktwirtschaftliche Kunden- bzw. Marktorientierung. Lediglich die Geschwindigkeit, die notwendig ist, als Marktteilnehmer mit sich ändernden Marktsituationen auseinanderzusetzen stellt besonders große Organisationen vor eine Herausforderung.
Organisation wird in der Regel mit dem Ziel gebildet, um ein Produkt oder einen Service einer breiteren Kunden-Gruppe anbieten zu können und damit Skaleneffekte zu erzielen. Ein fertig entwickeltes, bestehendes Angebot wird in der Regel industriell gefertigt, von einer horizontal skalierten und auf das Angebot geschulten Salesforce vertrieben. Alle Abläufe zu Herstellung und Vertrieb genau dieses Produktes können gemessen und hinsichtlich Kosten und Gewinn optimiert werden. Das ist auch, was anerkannte Business Schulen in der Regel lehren.
Innovation dagegen findet häufig in einem technischen Zusammenhang statt, mit einem herangehen, in dem zwar die Idee und das Ziel feststehen, noch nicht aber alle Schritte feststehen die zu diesem Ziel führen können. In einem kreativen Chaos, das es erlaubt, werden auf dem Weg kurzfristige Richtungsänderungen umgesetzt, das Ziel stets vor Augen.
Es ist nicht in das Korsett starrer “Business Prozesse” eingebunden. Die bestehenden Prozesse sind in der Regel auch langsam entstanden, führen aber zu anderen Zielen. Organisation und Innovation finden mit unterschiedlichen Zielen statt.
Digitalisierung fordert aber beides von Wettbewerbern, die im Markt bestehen wollen und Ihren Kunden passende, innovative Lösungen anbieten möchten. Das fordert ein Umdenken in beiden Bereichen.
-
Culture eats Strategy for Breakfast
“Culture eats Strategy for Breakfast” is a quote that is often attributed to Peter F. Drucker, but was apparently coined by Ford’s Mark Fields. Whoever said it, both have plenty of business acumen to take some credit for the thought behind it. There statement has lot of truth in it, looking into corporate structures.
With the arrival of digitalisation it is more true than ever before. All verticals struggle with fundamentally changing markets, forcing them to innovate in technology and services, and strive for new business models. In this environment it is crucial to embrace change, which enterprise culture often outright rejects.
Change Management has been a topic in management and HR for many years, and never has been so fundamental to organisational success as it is nowadays. Technology is converging at a breathtaking pace. The Internet of Things, as an example, requires electrical & mechanical engineers to cooperate with computer scientists and data analysts to produce a product a usability engineer designed jointly with a designer. Fundamentally different schools of though define the success of a product, and even consumer and enterprise grade of products converge in their appearance.
At the same time, the technologic ecosystem has outgrown individual organisations capabilities. Partnerships with technology vendors require management while intellectual property needs defence at the same time.
Organisations develop anti-patterns like “Silo Thinking” or “Not invented here” syndrome. While these cultural behaviours are tolerable in less dynamic situations, their effect can quickly go out of bounds and create a substantial counterforce to any change infused through external factors.
Embracing an open ecosystem and building on technologies developed outside the own organisation are fundamental to innovation. This open mindset is a prerequisite for any change into agility. Any strategy aiming for change ignoring these behaviours will be eaten by this exact culture. For breakfast.
-
Corporate Open Source
One concept that is under active discussion for the past decade or so but constantly being misunderstood. Open Source is often taken as a label for software downloaded from the internet, packages free of charge, components under a particular license filed under “Creative”. Often enough it’s misused for lower quality software, which reality has proven wrong by 2017, not to mention the issue with intellectual property.
However, there are many much more aspects to the concept, that add substantial value to any software centrist product organisation. And in times of digitalisation and digital transformation, software will move into the value chain of many organisation that don’t anticipate it yet. Whenever a customer offering is complex and / or service based, transparency and documentation are often key to a satisfactory result and efficient processes.
Open source may not be the one single bullet for any organization, but the concept will help becoming more transparent and efficient.
Single Source of Truth
While SharePoint is a powerful tool with many opportunities to improve processes, many organisations use it to maintain a file server. Which has information about any other effort, therefore creating a large spread between the tangible product and the then theoretical documentation. Not to mention the version horror everybody experienced at least once, trying to ask a few people for the latest version.
Reversing this process through Wiki or even Version Control Repositories allows to keep only one version, that is automatically the latest. Software will take care of all versioning, that would go in filenames_v01_final.docx otherwise.
Transparency
Adding together the product with documentation allows quick reference, pointing back and forth between customer facing and engineering. While this may sound terrible technical, the nasty guts of any product can still be ignored by those who don’t need to see it. However, for those requiring insight, they don’t have to go through a process to see it. Or even have to talk to a colleague first and ask. Oh, and the colleague will be on vacation anyway.
Opening the product internals will remove any barrier to productive work and allow employees for quick insight. Obviously, some may argue an open repository may lead to uncontrollable product results, but that’s actually a different point. Write access or merge credentials are not required for anybody without responsibility.
Applicable Metrics
To shape it all up, the management world has plenty of nice metrics that can be applied to measure the whole thing. Not all of them express quality by themselves, but applied consciously these can carry a product far.
Documentation Coverage is something that will serve as a great basis for the point I’m trying to make here. With closed projects, or engineering only code, it’s often difficult to understand whether a product, feature or bug is actually just badly documented or the colleague just doesn’t want to help.
With a metric to measure percentage of a product being documented, at a minimum the amount of available documentation can be measured. And with the product internals being transparent, any reader can – at least theoretically – see whether the documentation correctly corresponds.
Conclusion
While being a strong supporter of open source software in general, I’m not trying to make a point for open sourcing anything outside an organisation. However, transparency will help any organisation improve the offering and processes. And the concept of open source will help achieve this transparency. It has a hurdle to overcome, in particular management will have to overcome their fear of software and technology to adopt this concept, but the step is worth taking on the way to digital transformation.