This is why quite often these days on here or hacker news/reddit I jump to the comments before I even bother with the article

*Posted by the CEO of ImaginaryCloud

Agreed.

P.S. You dropped this \

I see it in the same way. Is in that sense that my recommendation would be to go with a Sprint in a first stage, but then, once the stakeholders are aligned with the general business strategy and goals, move into a PDP to materialize that in accordance to user needs and goals.

The limitation of one persona is a limitation recommended by the authors of the Sprint themselves. While certain you can go around this, the results will probably be impaired.

In terms of having separate groups working on separate personas, in practice that is not possible. It's not enough to validate in the last day if you have to build the app information architecture, the user journeys, the interfaces, etc...taking into consideration both personas.

And simply having one larger group to try to deal with more requirements in the same time-frame is not a solution - since co-designing and dealing with discussion and decision-making is difficult in larger groups (Once again, the authours themselves recommend small groups for the process to work).

". Don't have a "style guide" for visual execution? Not a problem. The goal is to come up with validated solutions quickly and cheaply, not design and build a launch-ready product. Knowing that going in, of course, it doesn't suit your needs if your need is to have final designs done in a week." - Yes, that's exactly the point of the article: Design Sprint is a process to test a product concept, the PDP is a process to have a product ready for the implementation to start. Unfortunately, many product owners don't realize this and have irrealistic expectations about the Sprint and/or try to adapt it for a purpose to which it is not suitable, resulting in products with poor UX.

Hi Adam, thanks for the feedback. We'll keep an eye on clarity from now on.

Taking this into consideration. I hope the article that was released this week is clearer.

I think that there is a misunderstanding here relative to the "level" that methodologies are applied. Agile is great at the product level. You want to define requirements, design, test, develop, test, repeat. Without doubt. But the PDP is not a process for the project level. It is a methodology at the phase level. It's about how to do the design phase.

It does not invalidate Agile. You can (and should) do a PDP, then move to the testing and implementation and then review the work done. But, in the design phase itself, you need to have some waterfall. Otherwise, you will be working ineffectively and ending by spending a lot of time and budget and have a poor quality design - plus an unmotivated team.

Giving you a very basic example. If you don't have any actual data to base your choices in terms of what colours and fonts to use, do you choose them based on what? It will end up being personal preferences or stereotyped assumptions from either the product designer or product owner... And then you will end by changing the look&feel again and again - something that, once you have dozens of screens designed, it's really time-consuming (and boring).

By doing some really quick preliminary research and methodic thinking you reduce the chances of this happening cause you are able to reduce a lot of risk from loose assumptions.

Also, sticking to this example of the colours and fonts (since it's the simpler one) the PDP solves one of the major problems that visual designers face - the communication of abstract concepts.

Stakeholders want the look&feel to convey certain values and feelings. The type of requirements that you get related to that, It's usually something like "I want it to feel luxurious"- But what does luxurious means? How do luxurious look like? More often than not, people have different visions of that. With the PDP, instead of receiving this requirement and jump into designing interfaces just to discover after that you were not aligned (and spending three times the time in changing it and changing it again until you get it right), you have the tools to explore and define the concept properly, so you can move on more efficiently.

Concluding, the PDP doesn't replace any project management methodology (and at the end, even if we recommend to go with a more agile approach, it can work with any PM methodology). The PDP simply brings methodology into the design phase. In those areas that not even the Sprint covers. And shines light into a process that (while is somehow already implemented intuitively by experienced designers) stills being talked and perceived as something kind of random and obscure by project and product managers and less experienced designers.