Another role or function that is often confusing to Germany high-tech companies is product management. Startups tend to get it right these days, but large organizations often remain unfazed by a lack of strong product management.
A product manager is responsible for defining the product innovation and associated business plan (strategic product management) as well as working out features to a level of detail (technical product management) so that they can be passed on to engineering. As the saying goes,
A product manager is responsible for building the right product, while an engineering manager is responsible for building the product right.
Open source is a viable business strategy for software vendors to disrupt existing markets and conquer new ones. Just why is it easy in some markets and hard in others? I argue that you need to cut the product in such a way that there is a clear separation between what a never-paying community-user wants and what a commercial customer needs. In addition, you need to tie the commercial features closely to your company’s intellectual property and capabilities to keep competitors at bay. If you can do that, you are in the right place. If you can’t, you may want to get out of there.
Abstract: The creation of domain models from qualitative input relies heavily on experience. An uncodified ad-hoc modeling process is still common and leads to poor documentation of the analysis. In this article we present a new method for domain analysis based on qualitative data analysis. The method helps identify inconsistencies, ensures a high degree of completeness, and inherently provides traceability from analysis results back to stakeholder input. These traces do not have to be documented after the fact, but rather emerge naturally as part of the analysis process. We evaluate our approach using four exploratory studies.
Foremost, a product manager works on products for a market (i.e. many customers). I have never seen a product manager work on a project with one customer. For a product owner this is undefined; they could be working on a product for a market or on a project for a specific customer.
I’m seeking advice on how to frame the research question for a research project (Ph.D. thesis) on software product management and open source. The simple heuristic “non-differentiating -> open source it, competitively differentating -> keep it closed” doesn’t cut it because of secondary effects like development efficiency resulting from open sourcing, market opportunities resulting from platform compatiblity, etc.
The best I could come up with so far are three different but related questions. These are:
For a non-differentiating function, which open source component to use?
For a chosen open source component, how to manage this dependency?
For a competitively differentiating function, when to open source?
Questions 1 and 2 are well-defined. Question 3 remains unwieldy. The heuristic mentioned above would answer “never”, but this is not true, as explained. Overall competitive situation and compatibility considerations may still lead to open sourcing unique intellectual property.
I’m seeking comments as to how practitioners (or other researchers) would look at this question. Any comments are appreciated.
Schufa is a German credit rating agency. By law it is required to provide information to consumers (while it makes all its money, for now, off corporate customers). As a consequence, its password and login screens have been designed, I suggest, to be as unusable as possible. Below please find a screen-shot of the PIN setting dialog, (The pin is the second of two passwords you need to login.) There are plenty of requirements. My favorite requirement is “use at least one special character but don’t use any illegal special characters”. Also, kind of amusing, the admonishment “to think really hard to remember your PIN”.
I teach product management at a public German engineering school, where I am a professor of computer science. Product management is my nod towards “business informatics”, otherwise I only teach engineering courses (and one general how-to-perform-research class).
There is an old debate as to who makes better product managers: M.B.A.s or engineers? Having worked on both sides of the fence and having gotten both degrees, I can confirm that as so often, the question is wrong: A hiring manager for a product management position needs to focus on skills and attitude, not on degree credentials. The degree may be an indicator of such skills, but it is not a sufficient indicator.
I’m looking for simple examples of product management failures and challenges that I can use in teaching our product management course. Photos or short stories would be great. To give you an idea of what I’m after, here are three examples.
This unmaintainable cup with saucer is probably a best seller, but I’d only give this as a gift to a person I don’t like. It will probably be destroyed during the first dishwasher run or will cause cleaning grief to the owner for many years to come.
A screenshot from Fitbit’s German website this morning. The issue is circled in red, a scale with a “feel-good” weight of 122.5. Amusingly enough, this only feels good if you live in the colonies. Germany is not part of it. Here, the metric system rules, not the imperial one. 122.5 on a scale will be interpreted as 122,5 kg, which amounts to a whooping 270 pounds. So much for getting fit with Fitbit!
The lesson for software design, of course, is that if you go international, you have to be culturally knowledgable and sensitve. And you have to pay attention to detail. That’s what we are trying to teach our students who are working hard to become product managers. Maybe we should add this example to our PM by Case collection?