Productizing Plone
CC Attribution 3.0 Germany:
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.
Stevens, Guido
Coming from a traditional web consultancy background, we've launched Quaive as a product-centric "built on Plone" solution. We still need our clients to be happy, and we still to a lot of consultancy. This talk highlights some of the tensions and pitfalls resulting from a hybrid consultancy-product business model. You'll walk away with insights on the importance of: design, expectation management, architecture, and balancing technical debt versus making a quick buck. This talk takes a product owner perspective and will be useful to both project managers working with clients, and to developers who want to deepen their understanding of the business side.
 Well, now it's time for product, productizing plan. This talk is from Guido, Guido Steven. And we are very glad to have you with us. Guido, thank you for being there. Well, that's it. Thank you. Okay, there we go. Yeah, it's weird to do the stock in my room at home and not seeing the community, not seeing the people that I'm doing the talk for. And missing the context of, you know, being together in the room. I think we've lost Guido. I don't think it's going to work. Sorry for that. I'm going to try to fix it. Okay, you're back. All right. Start again. You're mute. Because you. You mute. Sorry for that. Okay. Yes, I got a warning from zoom about being last. Okay. Yeah, so just out of our, it's okay. No problem. Okay, let's do that again. Start. Then we need to share screen. And then we need to find zoom. Okay. Okay. I hope you can hear me now and that's almost a problem. Properly set up. Yeah, I'm good. You can go. Okay. Let's go. My name is going to Steven's I'm the founder of quave and I will talk you through how we evolved from a consultancy driven approach to blown to the product approach that we have quave. Bit of an outline of the stock. I will give you a short tour of our design environment. I will go deeper into the problems that a consultancy approach poses with some live war stories from the field. I will go also go deeper into how we solve the tensions there. And finally, a bit of a summary on the remaining challenges that this poses for actually making a viable business out of that. So, for those of you who already have seen it, but also for those of you who haven't seen it. It's useful as a context for this talk as well. Everything I'm showing you here is actually our design prototype. So Quave is a social internet system community system we have a prominent social stream. We have a collection of apps. One of those is a calendar app. We have a new magazine in Quave. There's workspaces. Workspaces people can self manage with a member of the workspace. They can then share and collaborate on documents or in this case you can email that came in. There's events there's tasks which are seen here in the workspace. And there's very powerful search, which is faceted but which also has different variants optimized for different view. And yeah, I guess you can. But so this is our profiles, user profiles and they are very deep. So that's just a very whirlwind tour of the future side we have in Quave. And this is how it looks like now but it's not where we came from. So back in the day things were different. And where we came from is from a consultancy approach where we had big dreams and build big sites. We have a big project in the wrong track. We built big projects and we found out the hard way that one off doesn't scale. So you can build very nice solutions there but in the end what the client wants is not what our users will need. So there's a big tension there between building something that's actually valuable. And also because it's one off you get into maintenance hell. And the illustration is, I think, you know, it's typical for the challenges that you pose in a consultancy environment where you want to do your best for the customer. But the customer has some very clear ideas about how the solution should look like. And it's not necessary that these ideas are very optimal from either a user experience perspective, or from a from a product architecture perspective. So to give an example of how that bands out in real problems is this is a screenshot from an early iteration of a little app, which was used in a predecessor of Quave, a big internet solution. And the requirement for this was discovered only just before launch. So I prepared this project and they were ready to launch this and then just three weeks before launch, the customer comes and like, you know, we need to have the legal contracts in the database migration as well. And no one had talked about that before that there were legal contracts. So, hey, what do you do as a consultancy shop in such a situation. You create a contact contract object type, you know, context, a content type. You build some filters to do that database. You know the drill, you just build that. And it's what we now call developer design. Especially you have the requirements and you whip up a fast solution in development, because it was not budgeted that this need to happen at all. That's a loss. Next thing that happens is a redesign of the project that comes in. It's not aligned with the rest of the project so everything breaks here. And you show to your designer and he's like, what the hell is this. And then you need to fix the UX problems you need to fix the technical problems. Basically, you need to reimplement all that 50% of it. Before it's really acceptable and that's another loss. So you think, okay, we made a loss but now we have a nice legal app, let's sell this to another customer. And we can, you know, we could solve those losses by selling that at margin to our next customer. Why for the new customer has new requirements and the new customer doesn't like the old requirements of the old customer. So you have to build a new variant of the app for the new customer. And the old client doesn't want the solutions that the new client wants. So you also have to maintain the old friend of the app. So basically you have to backport all the improvements you're making for the new customer to the old app. So now you have two apps. And then what to do. The next thing that happens then is that we have a generic toolbar redesign going in which affects like all of the pages in our system, and not just the apps everything in our system. And then, you know, normally that's not it's a lot of work anyway, but then the legal app is special it doesn't conform to our design system. So by it breaks and actually bang it breaks twice and I need to upgrade to non standard apps. And nobody's going to pay you for that, because nobody said you should do it like this and nobody funded like that. So after years of this struggle, the conclusion is, we cannot afford to do things cheaply. That's actually saying by Alex builds a father but it's quite applicable in this scenario. So what to do instead. I call that a product state of mind. And I'm using it from a different angle. It's one interacting with clients that's where it starts it's like you know, give me a problem not a solution requests. So typically customers they ask for a button here. Or you know they want to tweak there, and they think they are helping you by putting it that way and also they, they are often like thinking just in terms of very you know that's that's the easy solution that's the obvious solution. So it starts with saying no to solution here saying no to a solution request. It's like, okay, tell me a problem, and let's analyze that problem, and let's generalize that problem. And it turns out that what the client wants is not exactly what her users need, because it's our job to actually fully understand that field and to work with design and with requirements analysis and knowing the constraints of design knowing the constraints of the technology to find out what the solution is and think through all the other cases. That's not our customers job or customers job is to understand the problem, and to, to communicate that to us. So basically means twisting the whole conversation away from future requests and talking about user stories. And then in a later stage, when you have a design and I will get to that you can show that it actually satisfies the problem. But first you have to understand the problem, and you need to first do the design. And the left you see diagram and it's not really about design but it is about the whole like workflow of you know going from a requirement to a thing that is a production. And the earlier you detect a problem or a bug, and a bug can be a design bug or a requirement bug. And the more you detect that the more costly it is. And I always say like, I've had a lot of customers who had messy business processes with inconsistencies and if you just you know take those one off and translate those into code and into design, because it's inconsistent requirements you end up with inconsistent code. We call that buggy code. So it's really like trying to move that detection as far up front as possible. And we do that by doing a lot of design, by taking a holistic picture in design so our designer, he has this holistic view of the whole system. And you cannot just do a like a local locally optimized solution and not, and then ignore the follow that has elsewhere you need somebody who takes care like okay if we change this, we're not consistent anymore with what's happening there. We need to solve all of that at once. We do that in what we call proto which is our design environment. It's our funded only system, which does not have any blown back and at that stage. We do that real fast. And it allows us to actually do proactive design or the design features, and we can actually show them to clients before we even actually build the system, we just have a design. And I think a lot of this comes down also to a misconception about what design is. It's, people see the beauty in the design, and I think it's about the colors and how, you know, how the rounded borders are set up. But that's actually not why it's beautiful. It's beautiful. Because design is not what it looks like it feels like design is how it works. That's a quote from Steve Jobs. And that to the to you know in depth into how it actually should work. What you can get as a work of art that in the way it functions and you know in the interactions that it offers. It just feels same. It feels nice it feels smooth. And that's the function of design. You still need to then sell that and how do you do that. So you then have this generalized design and you work with your clients to come up with a generalized design. And it's presented here on the slide in a linear fashion like find generic product value and solve this client's needs with the generic solution. But that's actually of course it's iterative you you come up with a generic, you know, an obstruction of what the client wants in a way that it can serve all clients. And you validate that with this specific line that the generic solution is actually fine for them. The way we do find generic product value is by aligning with product wide affordances. So that's stuff like the social feeds we have we have workspaces we have bookmarks we have workflows, we have user profiles we have search. So those are all you know generic affordances that are product wide. And you can mix those in new shapes to come up with new solutions for clients. And that basically means. That means extending solution patterns that we have in such a way that they embrace this new emerging requirement. And if needed we can also add a generalized app. If that's a new requirement so new that it doesn't really fit within any of the existing applications we have. Like I said you then solve the client's need with the generic solution. And it may be that you then need to parameterize configuration if needed. So you make like a small twist of the generic solution. And the key is to not make that a client specific design. It's more like we recognize that this product can be used in multiple ways, one of which is optimal for this client. But it will be useful for other clients as well. And it's still like a variety of the overall thing. It's a it's a configuration. It's not a fork. Finally you ship an MVP. You ship a minimally viable product. If you want to do it right and build a good product. There's no way that on for a single customer you can ship a kick ass feature that is fully worked out. Unless the client has a lot of budget that we can use it really hard but else you will need to amortize that over a longer time. You need to build something that is good now that delivers 80% of the value for 20% of the effort, which is the birth rule. And then later you can return to that if this and also that's actually good, because then this client gets to give it to their users. The users get to experiment with that they get feedback on that. And then all the initial ideas you have about how they should be evolved, they actually become grounded. They become changed by the practice and then you can build the extension later informed by actual usage patterns that you're seeing and actual requirements that people articulate. So what that ball is boils down to is that you should build half a product, not a half ass product. And this is Jason Fried from 37 signals. And I like that approach. It's like instead of building something that that is fully functional but you know, is weird. It's better to build something that is really slick and has a lot of potential to grow into the future even if it's not fully realized yet. It's still already useful. What it gives you if you manage to have that balance and get it right is that you reach a point where you can experience scale and synergy. So deployments are QA tested product wide, which means that if we do a deployment of a product and we talk about it like a product, it's like roll out to all our customers. We don't have to test the whole product for all our customers, we can just test our product. And then we make a few checks that you know the themes for these customers are still working, but the functionality and all the core interactions they're just in the product and if they work in one team they will work in the other themes as well. And it also means that we can have automated upgrades. So we can just script a new, a new point release, and it goes out. And like, and that then also translates into fully scripted deployment so the upgrades are scripted the deployments are scripted as well. On the business side in terms of maintenance and extensions, it means that we, we deal with this in a subscription manner. We have a client's players for subscriptions and we are, we are able to handle all of the effort that it takes to increase the quality of the product as a whole for all our customers. Well, we share the cost of that across our customers. It allows potential for cross sales or multiple customers they want the same feature while we can pull that money and build a better variety of that feature. And it also allows for upsell like we sold the future to one client, and we made a basically a lossy investment on that thinking that we can sell it to another client and actually we can. And then we, again, we can build a high quality product that way without necessarily building everything to a single customer. That's not all rosy. It still leaves some prominent challenges and product space, which I will go into for clients for developers and for the business side. Clients is the key here, and the approach here is to nib it in the book, which means no one of customizations. I googled for an image for the kitchen sink. I thought this is quite appropriate. If you follow the lead of that one client that you're currently working with, you will end up building a kitchen sink like that in the shape of a guitar because this client has a guitar. He wants to wash his guitar. He also wants to wash his hands. This is the optimal solution for this client. Of course, we all understand that the next client who maybe doesn't have a guitar. They may have something else. You know, it doesn't fit. So instead you design a solution that, you know, allows this client to wash their guitar without giving a guitar shape to everybody. And the solution pattern like I hinted at us before is that we have configuration as design product variation. So it's not that we hack the system for a specific client is that we actually in the design phase integrated the requirements for this client in such a way that they will be satisfied with the product. And an example of this approach is that the customer brands we have our themes, they are not software. So they are CSS only. Let me just quickly show you how that works. So this is one thing. This is not a client. This is not a client. It's a same product. Just style differently. On the developer side, it means that we as developers have to submit to the paradigm of design first, which means if it's not a broader if it's not in our design system. It does not exist. That's really hard as a developer you see something that isn't fully worked out you want to fix that. But you know we don't do that we we, while we try not to do developer design. And the solution pattern here is that we do design calls and design reviews with the designer. And then as example is for example we recently did a project for 500 error pages. If you see this design in the left pane as a developer, you see the support thing being under linked and you think oh that's a male tool, and it will point to the registry record for the maintainer email address, because you know how blown works and that's the obvious implementation. So I put that to the designer he says no no not a male to link. There should be link to a help page a support page. And I like, oh but we don't have the support page and he's like, yeah yeah it is there it's in the admin app, and then oh, we didn't build that admin app yet. So you have to go back there and then negotiate whether you can start up with a male to link. But still we then need to buy into the full vision of having the full solution for all of that there, and then working in and development and engineering working towards the design vision. So design is in the lead and then we follow and build it like that. On the business side that results in technical debt, which is unavoidable. We try to keep deaf and sync with proton so we try to keep the plowing system in sync with the design system that we have. So design is in the lead we are by definition we are behind. On top of that we have ongoing maintenance because we need to ship. We do make compromises while we're shipping, and then they come back and we need to return to that and approve that code. And the solution pattern here is also to do proactive design so to actually to invest more in the design and then to sell the solutions to clients, but also to make sure that design in design everything has been flashed out in such a way that once once we get around to fixing stuff on the development side, we actually do it in a way that moves it close, close up to the articulated vision and design. And an example for that is the admin app, which is the design here. We don't actually have this yet so well we have the functionality of having external apps. We currently configure those in Barcelona and so we're raw blown. That's of course not acceptable from a UI perspective, you know, Barcelona does not part of our UI it's like a workaround. So then we have an articulation of like, okay so once we want to build this properly we know how to do it. So if you don't work that way and don't manage your technical debt, you will end up with newspaper articles like the one I'm quoting here, the piece in the Guardian which which is actually quite that big nice piece about technical debt and they say like, So why did Blue Origin, you know fall behind to SpaceX and their conclusion is it's an immense amount of technical debt defined as engineering challenges that build up as a result of choosing a quick solution, rather than the best solution, which I think is quite appropriate. And so this is something that can kill your company if you don't take care. So there's a tension between customer intimacy or product excellence, traditionally in management speak but you actually both you need to work really closely with your customers without being captured by their requirements or by this solution you need to then realize an excellent product that they are satisfied with but that you can also sell to other customers. Should you do this in an agile fashion, gradually incremental or do holistic design and actually you need to do both. You need to work ahead and design, and still you need to be very flexible, both in code but also in the design it also needs to evolve. How do you handle technical debt, well it's unaffordable, you just need to manage it and you need to constantly keep investing in reducing technical debt because each time you're also incurring more technical debt. So this is off while I was preparing this talk I saw this stuff on Twitter. It's like, you know, somebody quoting a product leader from a well known company, and the product leaders as you know honestly sometimes I want to go back to my old job, which was more project oriented more feature factory, because people underestimate how hard this is you know this design this product to bring an approach. And then this guy answers like you know well he would like to go back to the future factory because he would be on the giving end a lot of the receiving end. I thought that was quite funny because you know it's nice to build new features. It's perhaps less nice to be a user of such features if they're not fully well developed. And it's certainly not nice to be the guy in the back room who has to maintain those old features that somebody else built. So, well, thank you very much. That's a very good talk. Very interesting.
 Well, now it's time for product, productizing plan.  This talk is from Guido, Guido Steven.  And we are very glad to have you with us.  Guido, thank you for being there.  Well, that's it.  Thank you.  Okay, there we go.  Yeah, it's weird to do the stock in my room at home and not seeing the community,  not seeing the people that I'm doing the talk for.  And missing the context of, you know, being together in the room.  I think we've lost Guido.  I don't think it's going to work.  Sorry for that.  I'm going to try to fix it.  Okay, you're back.  All right.  Start again.  You're mute.  Because you.  You mute.  Sorry for that.  Okay.  Yes, I got a warning from zoom about being last.  Okay.  Yeah, so just out of our, it's okay. No problem.  Okay, let's do that again.  Start.  Then we need to share screen.  And then we need to find zoom.  Okay.  Okay.  I hope you can hear me now and that's almost a problem.  Properly set up.  Yeah, I'm good.  You can go.  Okay.  Let's go.  My name is going to Steven's I'm the founder of quave and I will talk you through how we evolved from a consultancy driven approach to blown to the product approach that we have quave.  Bit of an outline of the stock. I will give you a short tour of our design environment.  I will go deeper into the problems that a consultancy approach poses with some live war stories from the field.  I will go also go deeper into how we solve the tensions there.  And finally, a bit of a summary on the remaining challenges that this poses for actually making a viable business out of that.  So, for those of you who already have seen it, but also for those of you who haven't seen it.  It's useful as a context for this talk as well. Everything I'm showing you here is actually our design prototype.  So Quave is a social internet system community system we have a prominent social stream.  We have a collection of apps.  One of those is a calendar app.  We have a new magazine in Quave.  There's workspaces.  Workspaces people can self manage with a member of the workspace.  They can then share and collaborate on documents or in this case you can email that came in.  There's events there's tasks which are seen here in the workspace.  And there's very powerful search, which is faceted but which also has different variants optimized for different view.  And yeah, I guess you can.  But so this is our profiles, user profiles and they are very deep.  So that's just a very whirlwind tour of the future side we have in Quave.  And this is how it looks like now but it's not where we came from.  So back in the day things were different.  And where we came from is from a consultancy approach where we had big dreams and build big sites.  We have a big project in the wrong track.  We built big projects and we found out the hard way that one off doesn't scale.  So you can build very nice solutions there but in the end what the client wants is not what our users will need.  So there's a big tension there between building something that's actually valuable.  And also because it's one off you get into maintenance hell.  And the illustration is, I think, you know, it's typical for the challenges that you pose in a consultancy environment where you want to do your best for the customer.  But the customer has some very clear ideas about how the solution should look like.  And it's not necessary that these ideas are very optimal from either a user experience perspective, or from a from a product architecture perspective.  So to give an example of how that bands out in real problems is this is a screenshot from an early iteration of a little app, which was used in a predecessor of Quave, a big internet solution.  And the requirement for this was discovered only just before launch.  So I prepared this project and they were ready to launch this and then just three weeks before launch, the customer comes and like, you know, we need to have the legal contracts in the database migration as well.  And no one had talked about that before that there were legal contracts.  So, hey, what do you do as a consultancy shop in such a situation.  You create a contact contract object type, you know, context, a content type.  You build some filters to do that database.  You know the drill, you just build that. And it's what we now call developer design.  Especially you have the requirements and you whip up a fast solution in development, because it was not budgeted that this need to happen at all.  That's a loss.  Next thing that happens is a redesign of the project that comes in.  It's not aligned with the rest of the project so everything breaks here.  And you show to your designer and he's like, what the hell is this.  And then you need to fix the UX problems you need to fix the technical problems. Basically, you need to reimplement all that 50% of it.  Before it's really acceptable and that's another loss.  So you think, okay, we made a loss but now we have a nice legal app, let's sell this to another customer. And we can, you know, we could solve those losses by selling that at margin to our next customer.  Why for the new customer has new requirements and the new customer doesn't like the old requirements of the old customer.  So you have to build a new variant of the app for the new customer.  And the old client doesn't want the solutions that the new client wants. So you also have to maintain the old friend of the app.  So basically you have to backport all the improvements you're making for the new customer to the old app.  So now you have two apps.  And then what to do.  The next thing that happens then is that we have a generic toolbar redesign going in which affects like all of the pages in our system, and not just the apps everything in our system.  And then, you know, normally that's not it's a lot of work anyway, but then the legal app is special it doesn't conform to our design system.  So by it breaks and actually bang it breaks twice and I need to upgrade to non standard apps.  And nobody's going to pay you for that, because nobody said you should do it like this and nobody funded like that.  So after years of this struggle, the conclusion is, we cannot afford to do things cheaply.  That's actually saying by Alex builds a father but it's quite applicable in this scenario.  So what to do instead.  I call that a product state of mind.  And I'm using it from a different angle.  It's one interacting with clients that's where it starts it's like you know, give me a problem not a solution requests.  So typically customers they ask for a button here.  Or you know they want to tweak there, and they think they are helping you by putting it that way and also they, they are often like thinking just in terms of very you know that's that's the easy solution that's the obvious solution.  So it starts with saying no to solution here saying no to a solution request. It's like, okay, tell me a problem, and let's analyze that problem, and let's generalize that problem.  And it turns out that what the client wants is not exactly what her users need, because it's our job to actually fully understand that field and to work with design and with requirements analysis and knowing the constraints of design knowing the constraints of the technology to find out  what the solution is and think through all the other cases. That's not our customers job or customers job is to understand the problem, and to, to communicate that to us.  So basically means twisting the whole conversation away from future requests and talking about user stories.  And then in a later stage, when you have a design and I will get to that you can show that it actually satisfies the problem.  But first you have to understand the problem, and you need to first do the design.  And the left you see diagram and it's not really about design but it is about the whole like workflow of you know going from a requirement to a thing that is a production.  And the earlier you detect a problem or a bug, and a bug can be a design bug or a requirement bug.  And the more you detect that the more costly it is. And I always say like, I've had a lot of customers who had messy business processes with inconsistencies and if you just you know take those one off and translate those into code and into design, because it's inconsistent requirements  you end up with inconsistent code. We call that buggy code.  So it's really like trying to move that detection as far up front as possible. And we do that by doing a lot of design, by taking a holistic picture in design so our designer, he has this holistic view of the whole system.  And you cannot just do a like a local locally optimized solution and not, and then ignore the follow that has elsewhere you need somebody who takes care like okay if we change this, we're not consistent anymore with what's happening there.  We need to solve all of that at once. We do that in what we call proto which is our design environment. It's our funded only system, which does not have any blown back and at that stage.  We do that real fast. And it allows us to actually do proactive design or the design features, and we can actually show them to clients before we even actually build the system, we just have a design.  And I think a lot of this comes down also to a misconception about what design is.  It's, people see the beauty in the design, and I think it's about the colors and how, you know, how the rounded borders are set up. But that's actually not why it's beautiful. It's beautiful.  Because design is not what it looks like it feels like design is how it works. That's a quote from Steve Jobs.  And that to the to you know in depth into how it actually should work. What you can get as a work of art that in the way it functions and you know in the interactions that it offers. It just feels same.  It feels nice it feels smooth.  And that's the function of design.  You still need to then sell that and how do you do that.  So you then have this generalized design and you work with your clients to come up with a generalized design. And it's presented here on the slide in a linear fashion like find generic product value and solve this client's needs with the generic solution.  But that's actually of course it's iterative you you come up with a generic, you know, an obstruction of what the client wants in a way that it can serve all clients.  And you validate that with this specific line that the generic solution is actually fine for them.  The way we do find generic product value is by aligning with product wide affordances.  So that's stuff like the social feeds we have we have workspaces we have bookmarks we have workflows, we have user profiles we have search.  So those are all you know generic affordances that are product wide.  And you can mix those in new shapes to come up with new solutions for clients. And that basically means.  That means extending solution patterns that we have in such a way that they embrace this new emerging requirement.  And if needed we can also add a generalized app.  If that's a new requirement so new that it doesn't really fit within any of the existing applications we have.  Like I said you then solve the client's need with the generic solution.  And it may be that you then need to parameterize configuration if needed. So you make like a small twist of the generic solution.  And the key is to not make that a client specific design. It's more like we recognize that this product can be used in multiple ways, one of which is optimal for this client.  But it will be useful for other clients as well. And it's still like a variety of the overall thing. It's a it's a configuration. It's not a fork.  Finally you ship an MVP.  You ship a minimally viable product.  If you want to do it right and build a good product.  There's no way that on for a single customer you can ship a kick ass feature that is fully worked out.  Unless the client has a lot of budget that we can use it really hard but else you will need to amortize that over a longer time.  You need to build something that is good now that delivers 80% of the value for 20% of the effort, which is the birth rule.  And then later you can return to that if this and also that's actually good, because then this client gets to give it to their users.  The users get to experiment with that they get feedback on that.  And then all the initial ideas you have about how they should be evolved, they actually become grounded. They become changed by the practice and then you can build the extension later informed by actual usage patterns that you're seeing and actual requirements that people articulate.  So what that ball is boils down to is that you should build half a product, not a half ass product.  And this is Jason Fried from 37 signals.  And I like that approach. It's like instead of building something that that is fully functional but you know, is weird.  It's better to build something that is really slick and has a lot of potential to grow into the future even if it's not fully realized yet. It's still already useful.  What it gives you if you manage to have that balance and get it right is that you reach a point where you can experience scale and synergy.  So deployments are QA tested product wide, which means that if we do a deployment of a product and we talk about it like a product, it's like roll out to all our customers.  We don't have to test the whole product for all our customers, we can just test our product.  And then we make a few checks that you know the themes for these customers are still working, but the functionality and all the core interactions they're just in the product and if they work in one team they will work in the other themes as well.  And it also means that we can have automated upgrades. So we can just script a new, a new point release, and it goes out.  And like, and that then also translates into fully scripted deployment so the upgrades are scripted the deployments are scripted as well.  On the business side in terms of maintenance and extensions, it means that we, we deal with this in a subscription manner.  We have a client's players for subscriptions and we are, we are able to handle all of the effort that it takes to increase the quality of the product as a whole for all our customers.  Well, we share the cost of that across our customers.  It allows potential for cross sales or multiple customers they want the same feature while we can pull that money and build a better variety of that feature.  And it also allows for upsell like we sold the future to one client, and we made a basically a lossy investment on that thinking that we can sell it to another client and actually we can.  And then we, again, we can build a high quality product that way without necessarily building everything to a single customer.  That's not all rosy. It still leaves some prominent challenges and product space, which I will go into for clients for developers and for the business side.  Clients is the key here, and the approach here is to nib it in the book, which means no one of customizations.  I googled for an image for the kitchen sink. I thought this is quite appropriate. If you follow the lead of that one client that you're currently working with, you will end up building a kitchen sink like that in the shape of a guitar because this client has a guitar.  He wants to wash his guitar. He also wants to wash his hands. This is the optimal solution for this client.  Of course, we all understand that the next client who maybe doesn't have a guitar.  They may have something else. You know, it doesn't fit. So instead you design a solution that, you know, allows this client to wash their guitar without giving a guitar shape to everybody.  And the solution pattern like I hinted at us before is that we have configuration as design product variation.  So it's not that we hack the system for a specific client is that we actually in the design phase integrated the requirements for this client in such a way that they will be satisfied with the product.  And an example of this approach is that the customer brands we have our themes, they are not software. So they are CSS only.  Let me just quickly show you how that works. So this is one thing.  This is not a client. This is not a client.  It's a same product.  Just style differently.  On the developer side, it means that we as developers have to submit to the paradigm of design first, which means if it's not a broader if it's not in our design system.  It does not exist. That's really hard as a developer you see something that isn't fully worked out you want to fix that.  But you know we don't do that we we, while we try not to do developer design.  And the solution pattern here is that we do design calls and design reviews with the designer.  And then as example is for example we recently did a project for 500 error pages.  If you see this design in the left pane as a developer, you see the support thing being under linked and you think oh that's a male tool, and it will point to the registry record for the maintainer email address, because you know how blown works and that's the obvious implementation.  So I put that to the designer he says no no not a male to link.  There should be link to a help page a support page.  And I like, oh but we don't have the support page and he's like, yeah yeah it is there it's in the admin app, and then oh, we didn't build that admin app yet.  So you have to go back there and then negotiate whether you can start up with a male to link.  But still we then need to buy into the full vision of having the full solution for all of that there, and then working in and development and engineering working towards the design vision.  So design is in the lead and then we follow and build it like that.  On the business side that results in technical debt, which is unavoidable.  We try to keep deaf and sync with proton so we try to keep the plowing system in sync with the design system that we have.  So design is in the lead we are by definition we are behind.  On top of that we have ongoing maintenance because we need to ship.  We do make compromises while we're shipping, and then they come back and we need to return to that and approve that code.  And the solution pattern here is also to do proactive design so to actually to invest more in the design and then to sell the solutions to clients, but also to make sure that design in design everything has been flashed out in such a way that once once we get around to fixing  stuff on the development side, we actually do it in a way that moves it close, close up to the articulated vision and design.  And an example for that is the admin app, which is the design here.  We don't actually have this yet so well we have the functionality of having external apps.  We currently configure those in Barcelona and so we're raw blown.  That's of course not acceptable from a UI perspective, you know, Barcelona does not part of our UI it's like a workaround.  So then we have an articulation of like, okay so once we want to build this properly we know how to do it.  So if you don't work that way and don't manage your technical debt, you will end up with newspaper articles like the one I'm quoting here, the piece in the Guardian which which is actually quite that big nice piece about technical debt and they say like,  So why did Blue Origin, you know fall behind to SpaceX and their conclusion is it's an immense amount of technical debt defined as engineering challenges that build up as a result of choosing a quick solution, rather than the best solution, which I think is quite appropriate.  And so this is something that can kill your company if you don't take care.  So there's a tension between customer intimacy or product excellence, traditionally in management speak but you actually both you need to work really closely with your customers without being captured by their requirements or by this solution you need to then realize an excellent product that they are satisfied with but that you can also sell to other customers.  Should you do this in an agile fashion, gradually incremental or do holistic design and actually you need to do both.  You need to work ahead and design, and still you need to be very flexible, both in code but also in the design it also needs to evolve.  How do you handle technical debt, well it's unaffordable, you just need to manage it and you need to constantly keep investing in reducing technical debt because each time you're also incurring more technical debt.  So this is off while I was preparing this talk I saw this stuff on Twitter.  It's like, you know, somebody quoting a product leader from a well known company, and the product leaders as you know honestly sometimes I want to go back to my old job, which was more project oriented more feature factory,  because people underestimate how hard this is you know this design this product to bring an approach.  And then this guy answers like you know well he would like to go back to the future factory because he would be on the giving end a lot of the receiving end.  I thought that was quite funny because you know it's nice to build new features.  It's perhaps less nice to be a user of such features if they're not fully well developed.  And it's certainly not nice to be the guy in the back room who has to maintain those old features that somebody else built.  So, well, thank you very much.  That's a very good talk. Very interesting.
Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_0_1607.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_1608_2051.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_2052_2207.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_2208_2507.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_2508_3059.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_3060_3923.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_3924_5339.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_5340_5675.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_5676_5735.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_5736_6479.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_6480_6635.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_6636_7115.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_7116_8699.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_8700_10487.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_10488_11231.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_11232_12263.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_12264_13727.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_13728_13871.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_13872_15803.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_15804_18359.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_18360_19367.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_19368_23507.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_23508_24131.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_24132_26807.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_26808_27131.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_27132_28895.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_28896_29159.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_29160_30587.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_30588_30983.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_30984_31115.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_31116_31439.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_31440_32807.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_32808_33539.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_33540_34451.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_34452_35711.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_35712_36935.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_36936_37055.png Productizing_Plone_-_Guido_Stevens_M5NvUcZjins_37056_37152.png