Open Source Product Management
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 9 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/65898 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS Backstage 20209 / 9
4
00:00
Successive over-relaxationGodProduct (business)Open sourceMetreAreaRippingIRIS-TGraphics tabletCollaborationismSoftwareOpen sourceComputer virusData managementProduct (business)Group actionComputer animationLecture/ConferenceMeeting/Interview
01:09
CollaborationismBootingDialectSoftware engineeringFingerprintBendingOpen sourceProduct (business)MetreRippingTranslation memoryRoundingLogic gateMagneto-optical driveDean numberWebsiteExact sequencePC CardData managementChi-squared distributionAddressing modeBridging (networking)Computer-generated imageryPrincipal ideal domainComputer fileTotal S.A.ElectronvoltMountain passOvalPrinciple of relativityCone penetration testStatistics4 (number)Computer fontCompilation albumDelay-tolerant networkingPlanningSurjective functionHand fanCore dumpRothe-VerfahrenIntelText editorMoore's lawIntrusion detection systemEmpennageBit rateInformation managementAbsolute valueDistribution (mathematics)ExistenceComputer programMeta elementProduct (business)Open sourceData managementLibrary (computing)PrototypeComplex (psychology)ExistenceSoftwareGroup actionPhysical systemParameter (computer programming)MultiplicationIntegrated development environmentLaptopHacker (term)Scaling (geometry)Multiplication signEqualiser (mathematics)Level (video gaming)BuildingService (economics)Category of beingNatural numberOrder (biology)1 (number)Suite (music)Elasticity (physics)Crash (computing)Cartesian coordinate systemCommitment schemeDivisorProof theoryComputer configurationMetropolitan area networkWave packetWeb 2.0Web crawlerFreewareNP-hardHypothesisInterface (computing)Computer programmingNumberPerspective (visual)Shift operatorExpected valueoutputBasis <Mathematik>Software engineeringProjective planeQuicksortSeries (mathematics)Inheritance (object-oriented programming)Right angleStandard deviationComputer animationXML
09:44
Information securityWebsiteDuality (mathematics)Product (business)FreewarePrinciple of relativityComputer-generated imageryAnt colony optimization algorithmsMetropolitan area networkInformation managementGraphical user interfaceSoftware developerBoundary value problemVirtuelle GemeinschaftIndependence (probability theory)PressureIntelMultiplicationImperative programmingControl flowConservation of energyMaxima and minimaTotal S.A.Angle of attackInterior (topology)Graphics tabletTetraederProduct (business)Open sourceGoodness of fitDecision theoryCartesian coordinate systemSet (mathematics)Self-organizationPressureAlgorithmDifferent (Kate Ryan album)SpacetimeSubsetCodeLevel (video gaming)Data managementCycle (graph theory)Information securityPrototypeExpected valueTerm (mathematics)AdditionOrder (biology)AuthorizationForm (programming)Field (computer science)Projective planeCASE <Informatik>Continuum hypothesisMultiplication signAndroid (robot)Direction (geometry)Exterior algebraFunction (mathematics)Service (economics)Representation (politics)NumberInternet service providerSpectrum (functional analysis)FeedbackGroup actionRight angleClosed setSource codeSoftwareFood energyElement (mathematics)Price indexInformationWhiteboardMatching (graph theory)Bookmark (World Wide Web)MappingSoftware developerPatch (Unix)Game controllerINTEGRALMetric systemData structureSoftware testingComputer configurationIndependence (probability theory)Office suiteoutputScaling (geometry)Sound effectLecture/ConferenceComputer animation
18:58
WebsiteFingerprintAiry functionMusical ensembleSoftware developerGraphical user interfaceTime seriesMeasurementProgrammschleifeFeedbackInformation privacyInformation managementCompilation albumArc (geometry)QuicksortNetwork operating systemMotion captureNP-hardComa BerenicesSineProgrammable read-only memoryMIDIApplication service providerCurve fittingRippingQuality of serviceCone penetration testInterior (topology)PlastikkarteCloud computingAreaDigital video recorderFunction (mathematics)Focus (optics)Complete metric spaceStructural equation modelingPrinciple of relativityOpen sourcePascal's triangleElectronic program guideSlide ruleConnectivity (graph theory)Data managementOpen sourceSelf-organizationCodeSystem callDifferent (Kate Ryan album)Annihilator (ring theory)MeasurementFreewareAnalytic setProjective planeInformation privacyDecision theoryComplete metric spaceDoubling the cubeSingle-precision floating-point formatFocus (optics)Profil (magazine)Product (business)Expected valueGroup actionTerm (mathematics)Standard deviationBasis <Mathematik>Latent heatJust-in-Time-CompilerReal-time operating systemRight angleCoefficient of determinationMotion capturePlanningRevision controlSoftware testingComputing platformPatch (Unix)Set (mathematics)Software developerFunction (mathematics)Classical physicsVulnerability (computing)Field (computer science)InformationPoint (geometry)Virtual machineData conversionCycle (graph theory)Interface (computing)CASE <Informatik>1 (number)Computer configurationAreaQuicksortTask (computing)Closed setService (economics)Computer animation
24:52
Computer-aided designOpen sourceAutomationFeedbackCompilation albumOrdinary differential equationForceInformation privacyPatch (Unix)WebsiteData managementEinstein-Podolsky-Rosen-ParadoxSoftware testingTexture mappingMetric systemStack (abstract data type)Presentation of a groupOpen setGreatest common divisorRootInheritance (object-oriented programming)WeightPolygon meshEvent horizonProduct (business)Wechselseitige InformationMetreBookmark (World Wide Web)Software testingProduct (business)UsabilityData managementExpert systemProjective planeElectronic mailing listFeedbackMobile appServer (computing)Self-organizationDirection (geometry)Patch (Unix)Formal languageArchaeological field surveyOpen sourceMappingInformation privacySource codeContext awarenessSoftware developerInformation securityHorizonCuboidComputer hardwareFunction (mathematics)Integrated development environmentCartesian coordinate systemCASE <Informatik>Traffic reportingInterior (topology)Universe (mathematics)EmailoutputArithmetic progressionSoftwareGame controllerMetric systemPhysical systemSpacetimeInteractive televisionPlug-in (computing)Different (Kate Ryan album)Axiom of choiceSphereStandard deviationPresentation of a groupLattice (order)DialectOrder (biology)Connectivity (graph theory)Functional (mathematics)Kanban <Informatik>Machine visionDecision theoryWeb applicationPoint cloudLatent heatOnline helpComputer animation
30:40
Event horizonProduct (business)MetreGraphics tabletSoftware developerProjective planeDependent and independent variablesCustomer relationship managementPosition operatorRule of inferenceData managementBitGoodness of fitRevision controlDirection (geometry)Integrated development environmentProduct (business)Normal (geometry)FeedbackSelf-organization1 (number)AuthorizationWaveBranch (computer science)Computer clusterMusical ensembleAreaRootInformation securitySet (mathematics)Perpetual motionOpen sourceDifferent (Kate Ryan album)Software bugDiagramGroup actionSoftware frameworkBuildingConstraint (mathematics)Right angleOpen setCycle (graph theory)Computer-assisted translationArithmetic meanOnline helpComputer animationLecture/ConferenceMeeting/Interview
Transcript: English(auto-generated)
00:04
Hello. Maybe we should make a start. Thank you everybody for your attention. So who wants to make open source software better? Yes? Yes? Say yes if we want to make
00:21
open source software better. Yes, we want to make it better. Yes? Yes, we do, right? And that's what product management is about. That's what product management is all about. We're about managing products better to serve users needs better. And that's what I'm going to be talking to you about now. And I'd like to ask, I've already asked a few of you individually, but I'd like to ask you as a group, do
00:40
we have any professional product managers in the audience? I have a director of product here. One at the back, thank you. Two, don't be shy. Anymore? Anybody who has been a product manager of any kind of product? Excellent. Three more, so we have five. And I know that we have some people who are completely unfamiliar with product management as well in the
01:01
audience. So I'm going to try and bridge this chasm and introduce you to some principles and get onto quite quickly the challenges and opportunities that are unique to product management in open source. So first off, for some of you, I might need to justify the need for product management before we get into the details because we can expect a lot from hackers on their own in
01:26
situations much like this. They produce wonderful things without any managers, right? Great ideas, products, even some one or two billion dollar open source companies have come out of hackathons and hacker situations much like this
01:42
without any management at all initially. So maybe we need to justify the need for management before we go further. First off, I would say creating value is difficult, very difficult in fact. And that's partly because complexity grows
02:00
and grows as we use more libraries and we deploy to more systems and we want to deploy more quickly and we want to be able to do more, more reliably and we want to automate more. Complexity increases and that helps to have a manager overseeing things so that we meet expectations. And also creating value
02:20
is hard because when you build something it doesn't mean people will come. Like these ghost cities in China circa 2009, 2010 made to be occupied by hundreds of thousands of people without a market because of the financial crash that happened before. If you build it they will not necessarily come and it's
02:43
expensive to build things when people don't come and use them and also quite disappointing for one's ego and one's team and one's supporters. So it's nice to build something that people actually want to use and management helps with that too. But even when you meet people's demands and you create value
03:01
upfront, initially you get it right once, you get a nice launch and a splash and things are going swimmingly, well things can change quite quickly because people's expectations shift depending on what other options they have and just because your spider web was the most attractive option for flies to commit suicide yesterday doesn't mean that some bastard won't invent flypaper tomorrow
03:21
and you'll lose all your users. So you need to stay focused on what people want in order to stay competitive because if you don't stay competitive then you don't have any users. Additionally assumptions are inherent to our thinking as human beings and maybe some of you are familiar with this cartoon, it's very difficult to shift our perspectives on a
03:43
habitual basis to perceive what others do from the same source input and actually that is something that requires skill and experience both training and and experience to avoid those assumptions because as many of you will know assumptions make an ass out of you and me and there's all kinds of
04:02
assumptions built into products. I'm currently designing a new product myself right now and the number of assumptions I'm making is quite terrifying so we have a lot of work to avoid these assumptions and having managers who are experienced at teasing out the hypotheses hidden in the software that we're designing and the way that we're deploying and the messaging that we're
04:21
using, that is a really critical skill and it's a skill among many other skills that having a technical background doesn't necessarily prepare you for very well. Many of us in this room I suspect will have spent the bulk of your careers on improving your technical skills, becoming technical
04:42
leaders and in that time that you were spending getting to be a perfectly clean coder and improving your standards and expectations, automating everything you may have neglected to be developing some of your other skills like user research or compliance. That's super exciting right? Culture building
05:02
important in both open source community projects and company run projects. Fundraising either from investors or from grants depending on where you're seeking your backing. These are things which having a long and successful history as a software engineer it doesn't prepare you for actually and as an engineer these other skills they can feel like a
05:23
series of traps that you walk into one after another like nobody told me I had to be great human resources just in order to keep my voluntary team together. Well yeah you kind of do right? Understanding people's needs and predicting them and making sure people feel comfortable and avoiding harassment and all sorts of other issues they don't come necessarily
05:40
naturally to people who've got technical skills. Doesn't equal project success. Finally some of you may be smugly thinking well actually you know Sam I do have all those skills I've learned my lessons I've been doing it all this time and congratulations to you because that's hell of an achievement. If that's your situation you still might have trouble convincing others to recognize those skills particularly others who have a lot
06:03
of money which you might need to either kick off your next project or make it sustainable or buy into it as your first users or customers or back you as a government agency if you want funding support from something like prototype fund or others. So having people who have successfully proved they can build products as product managers can be very useful for convincing
06:24
people with resources to back you even if you know you already have all of those skills inside you. If we want to build world-class products which are open source then there is an argument that we should adopt some methodology from those global companies which are teaching our children and our friends
06:42
what it means to be a world-class application today and those companies all use product managers. I was talking to one of our audience members from Elastic and they have lots of product managers. Many big companies have many many product managers and some of them are rock stars. Sometimes product managers are called CEO of product. Sometimes they have an ego to match. Sometimes
07:03
they have reputation to match but they have a huge influence over what the product becomes and how well it suits their needs. So for all these reasons product management I think is important to open source. Before we go any further it's worth converging on a definition of a product. Let's do this quite quickly. A good or a service that most closely meets the
07:24
requirements of a particular market and yields enough profit to justify its continued existence. I think this is a good definition of a product. If we adapt it to a community-based product then we could reword it as a good or service that closely meets the requirements of a
07:42
particular user group and yields enough resources to justify its continued existence. What's important about this is that products are for specific groups of people. They're not just for everybody and they need to be sustained one way or another because they consume resources and it's not primarily for you as the person who makes the product. We're not just
08:02
making something for ourselves or making something for other people and probably an awful lot of people because the nature of software is that it's expensive to make and it scales very well. So we want to ideally target a lot of people with something specifically for them and then we have a product. But that's a product in general. What about a product in
08:24
software more specifically? Well we can lean on a sage of the past, Mr. Fred Brooks who wrote an excellent book in 1975 called The Mythical Man Month who defined a software product as going through four stages with a three times multiple between transition of each of these stages. So often
08:45
open source starts out as a program which we have here top left. That's something that works for me. It works on my laptop. You might think of it as being a prototype or a proof of concept for example. And many people look at this and they think this is a product. This is complete. This is
09:00
ready. I'm so happy with this thing it scratches my itch I'm going to launch it to the world. But actually they're a factor of nine away from what other people would consider a product which is something which is not only a proof of concept that works on that environment for that person needs but actually has interfaces to other systems is integrated with other necessary systems is tested is generalized so it works in other
09:23
environments is documented and is maintained because a hidden expectation of just about every use of every piece of software ever is that it will continue to be improved and maintained in future which is something that crowdfunding campaigns often forget when they raise enough money to do one thing and then don't realize they've just raised the
09:40
expectations of 20,000 people that there's going to be a lifetime of free updates following. And all of this makes making a product hard. Anybody not think making a product is hard. Good. Then you'll be interested in why it's especially hard to make open source products
10:03
making value is our goal rather than making features. And this can be a culture clash when we are looking at open source communities because when we check on GitHub what the health of our favorite open source application is we will be looking at when the last releases and
10:20
maybe we might check the release notes and see how many things were in that. And that's all about measuring output rather than measuring outcome. And yes it is one way of measuring the health of a project or a product but it's not an indicator that it's going to meet your needs or be delivering value for your other people. So this
10:40
is one of the first challenges that we have. The term value isn't widely used around community based open source products. They have other terms which are valuable in other ways but I'm going to be talking a lot about value. I think this is a very helpful way in to what we're going to be discussing and the ways that product managers typically pursue value with their activities are
11:05
these user research user story mapping prototyping of products sprint management or the development cycle management acceptance testing and metrics monitoring. And these are all to do with what we call a virtuous feedback loop of interviewing testing
11:24
reporting back data and improving which we'll come back to in just a few minutes. Now before I get into more details about the different kinds of open source product management we need to recognize that different organizations are on a continuum. Some people may object to me putting Android and Docker on the
11:42
left but everybody in the room is probably on this scale. I'd like to ask how many of the projects represented here today are purely company managed where the community has no direct control over releases or priorities. Show of hands please. Everybody has community input. OK. So who is at the other end
12:02
purely community projects where companies they don't have to worry about they have to worry about commercial entities telling them what to do. Two only two. OK. What projects are you guys from. And Doc. Very nice patches a beautiful example of
12:25
that. And so does that mean everybody else is a hybrid or do we have some people not working in open source. Sorry. OK. Very good. Exactly. No it's a beautiful example. And depending on where you are on this spectrum different
12:41
levels of challenge and opportunity arise when it comes to product management because if you're basically operating like a regular company that dumps its source code then you don't really have to worry too much about the stakeholders because you're probably going to be not paying that close attention to what they need. If you're on the community end then you work completely differently from that. You can't
13:01
take the traditional autocratic approach and do whatever you you know make decisions that purely serve your commercial ends. Right. So our first challenge in open source when it comes to product management which our proprietary alternatives do not face is that we have more stakeholders right. We have a lot more stakeholders. Often
13:21
we have the same number of stakeholders as typical proprietary software products. But in addition to that we obviously have a community and the kind of representatives that we have in that community vary depending on where we are in that spectrum. But there's a good chance it will include all these people. It may even include governance. I know that we have LibreOffice here today for
13:41
example. They have built into the legal structure of the organization a membership committee and a technical steering committee and those are additional stakeholders which most product managers have never even literally dreamed of right in thinking about having to communicate with and keep on board a group of other organizations
14:03
who are third party on a technical steering committee. Well that's another level that will shock other community other product managers. But you might also have a business community around your open source product too which bring all their own needs and expectations. You might have independent service providers people who are building products and
14:20
companies around the value that you're creating and maybe you care about them and maybe you don't but they have expectations. Maybe you have downstream integrators who are taking your product and including it in another thing packaging it differently or maybe you have downstream forks like SAP who has internal forks of all kinds of open source applications including TensorFlow and everything that happens upstream affects them and they're likely to tell you about it if you do something
14:41
which causes them with problems. These are stakeholders which basically result in you having fewer decision making options fewer less latitude you could say to make top down decisions which of course is a good thing because they're feeding you information at the same time but it makes it a
15:00
good thing because in addition to all those other skills that product managers are expected to have the emotional intelligence to keep people happy at all these different levels you also have these stakeholders who will put additional pressure on you quite possibly publicly if you make a decision which affects them in a way that you didn't anticipate. In addition to the stakeholders we also have transparency. We have
15:23
a whole nother level of transparency to deal with in open source. Primarily prioritization is whether it's formal or informal we need to communicate as product managers what use case we're prioritizing what features what timelines and sometimes we
15:42
need if we're working for a company to prioritize things which are unpopular with the open source community and we might need to justify and explain ourselves in a way that if we're working in a closed source company again we would never have to think about. So informal prioritization would be when we just give more thought more time and more energy to pull
16:01
requests from certain representatives or from in relating to certain functionality whereas formal would be when we're saying for example we're not going to release Drupal 8 until this feature set is ready because that's a really important set of features for this release and for the people that we're trying to impress as an organization. We have to be transparent about
16:22
that. We also have to be very transparent about authority and expectations because there is always authority and there are always expectations when they're not clearly defined they're still there they're just ambiguous and causing more confusion. So governance is one great way of clarifying these things in official documents but it's
16:43
amazing how users expectations can run riot when you don't keep them in check. And we need to be explicit to avoid upsetting users with unrealistic expectations or expectations that don't match with with what we have. We have multi-dimensional quality so we're not just
17:02
gauged our success. The success of the products we make is not solely based on how efficiently that product solves the problems it's designed to solve but it also incorporates some of these other things we've just mentioned. So if we have good governance in an open source project that's considered by many to be one of the aspects of the quality of the product which
17:20
again is not something you'd have to think about if you're just producing a proprietary application. Yeah. Number of different aspects of quality which others don't have to consider. And again we can expect a public debate when we fall short on people's expectations of the quality of the product. Of course security is
17:41
imperative for everybody but in open source as many of you will be familiar it produces a particular set of pressures and questions with a new application. Obviously there's likely to be as many people trying to break the code as users use it and we just have less breathing space. Yes it's a good thing we can't lie. It's a good thing that we can't misrepresent the hashing and the algorithms that we're using
18:01
but at the same time it puts enormous pressure especially on small projects who may not have the resources to respond very quickly. It's a unique challenge for us and all these things add up to us needing additional leadership discipline in the management product management field than our counterparts often would in the proprietary side because what we
18:20
do is being seen what we are the decisions that we're making require us to walk the walk not just talk the talk. We don't have coercive authority or other forms of management authority to lean back on and to rely on. We've got a bunch of community members and contributors who can take their effort elsewhere and don't rely on us for their
18:41
paycheck. So we really have to practice what we preach which is a challenge. Finally we have less data in order to make these product management decisions that we want to. Earlier we saw the feedback loop here somewhere in my
19:04
slides which I've lost but a critical component is data for making the good decisions that we need to as product managers. We can't come through this virtuous iterative cycle successfully if we're not measuring the impact of the decisions that we're making and the improvements that we're applying. So validated
19:25
learning becomes more challenging and that's partly because our users have a double standard for open source products versus the proprietary products that they're using when it comes to privacy. Again of course we should expect privacy and many people like and support open source products specifically because they have more faith in it because the code is
19:41
public. But that makes measuring the success of what we're doing extremely difficult extremely difficult. If you go to any startup conference and listen to a talk about product management they will be talking about all kinds of data data galore. You can get it for free. There's free startup plans for all these analytics platforms all these you know conversion automation platforms that we don't
20:01
have access to and we should not. Our users expect very different things from us when it comes to the telemetry that we collect and the amount of information that we build up on them the profiles that we have. They also don't necessarily expect us to grab them for an interview in a Jitsi call or WhatsApp call to talk about their needs. But that's quite normal
20:22
with product management in the private or the proprietary sector. If we do include measurements then they may be removed. If we do include measurements then we may damage our brand. I'm reminded of GitLab a few months ago which slipped a terms of service update into our mailboxes for the self-hosted users which seemed all very boring until people realized
20:42
that it meant they were embedding a third party analytics platform within the self-hosted version of GitLab which prompted a crisis back peddling and a public apology from the CEO and also months of work being reversed and the roadmap for the product being changed. These things have consequences. We wouldn't think twice if we were a proprietary company about including that because first of all our users
21:01
may not know and second of all they probably just wouldn't hold us to the same standard. All of that means that we have less insight into the user experience of people with our product. We don't know what they're enjoying. We don't know what they're hating. They may give us feedback via GitHub issues but that's
21:20
different from actually knowing how they use it because what people say and what people do are very different things. People don't necessarily have insight into what their pain point is or into why they stopped using a product or what they felt uneasy about or why it wasn't as competitive as another product. That kind of information is especially taken from monitoring what people do and seeing what they do in
21:40
real time and again if we don't have that then we can't make those decisions. And that makes it hard for us to identify the value of the products that we're making. And if we can't identify the value of the products that we're making like for example using Miele washing machines in rural China to watch potatoes instead of clothes. If we can't know what people are doing with our products that is
22:00
different from what we expected then we can't improve the experience further for those users and we can't capture the value of those users. We can't capture any of the value of that experience which is important for making our product sustainable and resourcing ourselves to be competitive. We also have very few open source tools in this field like AB testing
22:22
tools analytics tools telemetry tools. That's one of the weakest areas in my experience for open source options versus using proprietary ones. And if it's not open source then there's a good chance we won't be able to self host. And that means not only would we be using proprietary analytics tools but we'd also be sending our users analytics data to the United
22:42
States to come back to us which is doubly problematic. We also may have culture clash right. So many open source products are founded by single charismatic technical leader and technical excellence may be the basis of a product but it is not a recipe for success for
23:03
long term product development. Technical leadership can maintain a focus on output again rather than on value. And it may mean that we end up with other companies or even potentially community projects which take the code that we're making as an open source
23:21
community oriented projects and do not have the same restrictions or the same pressures from their community because they don't have one. So they take what we make use traditional closed decision making practices and capture the value that we are not as the open source upstream project which is particularly challenging. And it also means that focus and
23:42
coherence can be very difficult when we have a culture that's focused on releases because we need ultimately a coherent set of features that work together to achieve certain tasks that solve particular user needs. And when we have people making suggestions and requests and submitting code and patches from all over the
24:02
ecosystem from all sorts of different use cases it makes it difficult to have a product which is unified with an interface which is well tailored to one specific group and one specific set of challenges. Focus and coherence becomes very difficult when you're trying to meet the needs of everybody because everybody has an
24:21
opinion as kind of contributing. However having gone through all those challenges I can say all of which I've personally felt in different organizations and different kinds of products in the past there are advantages that we need to recognize and take advantage of. So first off many open source projects start out by dog foodings scratching the itch it's the classic right. Eric S Raymond etc. Well if you're
24:42
scratching your own itch then you are scratching an itch. It might not be everybody's itch but at least one itch is being scratched and that's what we often call dog food which is when you eat your own dog food and you test your own product and that helps get you off the ground and stay focused on solving at least one problem. Our large and diverse user base means we get large and diverse input which is the flip side of some of the
25:02
challenges I was mentioning earlier. That means we get reports from outer space effectively running in operating systems and environments and hardware and use cases which we may never have dreamed of. All kinds of people seek out open source as their first choice which otherwise you wouldn't necessarily have heard of in different languages and regions and
25:20
contexts which is wonderful. In the past I've had security reports from universities who I had no idea that were using us they're open source they come out of the woodwork and it's great. We have more eager testers typically people who may produce high quality reports they're more expert in their field and if we're lucky we get even patches although I wouldn't hold your breath unless the product is aimed at technical users. As somebody
25:41
who's made marketing products in the past that are open source we had very little patches I must say. Additionally we get a lot of feedback. It is self-selected feedback which can be a challenge because it doesn't necessarily represent your user base but it's thick and fast and you can expect it to continue which is great. It's cheap to sit there and wait for people to test your
26:00
product and use it and tell you how it went rather than having to go out or pay for research. We can't avoid having cutting edge ideas because we have a very technical community of open source developers typically and like it or not they will pull you into the 21st century and make suggestions about how to release it better and manage it better and automate things better which is wonderful. We also are forced into best practice. We have here
26:22
chefs working in a glass kitchen and that's how it feels right. If our product management if our prioritization if our decision making if our governance is all in the public sphere then we have no choice but to basically be at the cutting edge because otherwise people will point out that we're not. If we don't take into
26:41
account ethics in our licensing and workplace practices people will see it more clearly because people tend to be more vocal around our projects. We may even get fairer governance if we are lucky and we put effort into it but we can certainly expect to be held to a very high standard when it comes to data management and privacy and that's great. We held to a high standard.
27:01
It makes us better as individual product managers and it makes our products better. Yeah. Folkability. That's just what I put in. So one of the upsides is if you don't like how your senior management is treating you then theoretically you can take the source code and run it in a different direction. Cough next cloud cough. So when we look back at the typical activities of what product managers are
27:22
typically doing in any kind of organization these aspects of user research prototyping et cetera then we do have open source tools to help us with this and some of them are pretty good. So for the user research side I've used OBS studio for doing recorded interviews. You can also use multiple cameras there. It's very nice
27:41
see what the user is doing with your product. I know that we have usability experts in the room who've used similar approaches with improving Thunderbird usability and others. PHP list is nice for sending out a lot of emails with invitations to give feedback and surveys for example customized to different
28:01
languages et cetera. For user story mapping I got to recommend post its technically I don't know it may be debatable if it's open source but paper is actually better for some things. But we also have a nice app called twinary. There's a bunch of other apps here I'm not sure how familiar you are with them. I draw your attention to prototyping. Yeah thanks to Elio for reminding me about UX box yesterday. Yeah
28:21
they're work in progress UX box in Akira but there's some bright stars on the horizon. These are both recent applications very modern and meeting needs. I'd also recommend presentator if any of you have used in vision it's quite similar in the functionality that I need from it. Very nice very modern looks pretty nobody will know the
28:40
difference at least all the people I've worked with. And yeah a bunch of other apps. We tend to use metomo for our metrics monitoring. It's open source it's got a lot of fine grained control over privacy which is super helpful. They've got proprietary plugins which are good for a B testing and monitoring specific aspects of the user behavior and interaction if your product is web
29:01
based. If your product is app based then there's a nice open source competitor to metomo called countly which you can deploy as your own server. They've got venture capital it's pretty professional product it's yeah fully open source and geared entirely to metrics on the app front also iOS. Wasabi is pretty nice for a B
29:22
testing but it's not so well maintained these days. It's heavy it comes from a big American tax firm which wanted to a B test their features but unfortunately aside from Wasabi I don't know of any good a B testing solution that is similarly API driven. And sprint management maybe
29:40
you're familiar with these open project is my favorite Scott burned down charts Kanban and a bunch of other things for the backlog grooming. Ultimately we want to make better products with open source software. We want to fulfill our user needs better as you all cheered at the beginning we're united in that goal. Product management is a critical component to
30:01
making those open source products better to making us competitive to understanding our user needs and to delivering the value that we need in order to get millions and billions of open source users for the products that we make rather than hundreds or thousands. And finally I would leave you with this to make outcomes in for outcomes rather than making releases.
30:22
Remember that it might not be popular amongst your engineers but it's something that's critical to always keep in mind value over output. And that's it for me. Thank you for your attention. Anyone in the scrum
30:55
framework would you say that beyond besides the PO that should always also
31:00
be a product manager or is it the same? What do you think about these two roles in a scrum environment? I don't think there's any universal rule for that like the cultures varied from organization to organization it depends on the skills you've got and the origin of the team. But they can certainly work
31:21
very well together complementarily in my experience I've had both a product manager and a product owner in the same team in the past. But obviously defining roles is important and areas of authority. I actually worked side by side as basically me as a product owner and somebody else as a product owner
31:40
simultaneously in a previous organization that worked pretty well for a while I like that it's not something people advocate. Also my scrum certified trainer said that was a bad idea but for me it was it was okay. So yeah I mean also an open source obviously community management is very close to what we've been talking about because those stakeholders need to be involved and managing their feedback
32:01
is important and difficult as I also heard earlier from the audience. So in sales agility for example a company which makes sweet crm the community manager and the product manager are the same which seems like a huge amount of responsibility for one person to me but also I think it also makes some sense. So it depends on your strengths too I think as an
32:20
individual and what you like. Is it the inherent role of the product manager to impose some pain to the actual tech leads or
32:40
the tech developer crowd to steer in the right direction that as you said create value or is there also a painless way possible or thinkable?
33:01
That's a great question. Steering doesn't need to be painful if you're really good but yeah there's a conflict of interest and that's good and that's inherent and I think that's necessary as well because you expect as a product manager you expect certain things of your technical team and they expect certain things of you.
33:23
Yeah with the diagram I had earlier with the intersection of traditional roles. I skipped past it but it relates to this quite directly so we can look at the business role like so these are different skills or
33:41
backgrounds you would you know typically recruit a product manager from the business side is like understanding the needs of the user understanding you know what the market wants. The tech is about the constraints of what's possible what's achievable and then the UX would be how you can package that up in a way that those two things match so the constraints necessarily conflict with
34:01
what the demand is I would say and so does UX but that doesn't mean that you you need to be creating pain but it's also not a bad thing if you do I would say if they're not too contradictory. Anyone else?
34:28
Thanks for the talk. I'm not sure that that's a good question but I was wondering in in like the really open in the the open source projects we've had
34:42
which have open governance like Apache projects GNOME or what you mentioned there like how I have you have you worked in such environments and how would you position yourself as a product manager there because obviously there because of the open government small
35:01
you can't just enforce your product manager rule there so the question is how do you how do you communicate to the project that you should be a product manager how do you grieve other product managers in the project and yeah how do you convince the community of your position there? I think it's a great question and I
35:21
think there's probably people better qualified to answer than me. Do we have somebody from the Apache Foundation or Apache project? Yeah can you please? Thanks. So I think in in some ways there will be companies behind successful Apache projects and not just one. You do get some very small ones
35:41
that are a group of people really keen but often there'll be a bunch of companies and they'll have direction and then as a community the community kind of weighs up that and says oh company A is really keen on that feature no one else is. We're gonna let him get ahead go ahead with it but it's not going to slow anything down we're not really gonna help that
36:00
one over there's three companies involved we all think that's really keen we've got a lot of good feedback let's come together and then let them drive that a bit and so you might say oh next release manager or company B is really keen their product owner is being really helpful and they've been good we're kind of going to make them the release manager and let them define done for this release and if
36:20
they're great then we'll recommend again and if they're terrible then we might take it off them or we might just let them do it once but as a community you kind of come together and say between all of us what do we mostly want and who's actually going to step up and do the work that's key you can you can write roadmaps so the cows come home but if no one's actually going to code against them then it's a bit pointless so it's it's
36:43
a little bit cat herding a little bit people stepping up a little bit people being permitted to step up but it also doesn't happen as quick as a product manager you can say by the end of the next scrum even if you have to work late we're going to get this feature out with an open source community you'd be like probably by
37:01
the end of the next quarter or as long as no one has too many good Netflix shows we might get this feature out but you can't just like deprioritize fixing that critical security bug that no one else knows about yet for a cycle right and things like that but then if you're building your business on top of it you might say you know
37:20
what that release isn't out yet but that feature set is fine so we're going to take that branch and bake that into our commercial products but that's you as a company saying that's done for us not you as a community which takes longer thanks and do we have somebody else from the document foundation I'm a member that would like to speak to this document
37:41
foundation people okay well I won't answer on their behalf yeah I always feel bad when I make microphone people
38:01
walk far and so I get quite a lot of them well a reasonable amount of PMs asking me after talking about open source design asking about where they can go to contribute product management in an open source way so where is that and I honestly I'm not quite sure where best to direct them there's a few projects around but
38:22
do you know where best to direct so you're asking people who have product management experience how they could contribute yeah that's a brilliant question your answer is no I don't because it's not something you can swoop in on and do without really understanding the roots and the culture
38:40
in a project I think but I'm sure if we think harder we can come up with a good answer to that so let's talk thanks anyone else thank you
Recommendations
Series of 10 media