Put the “V” in MVP

Posted on by spereira.marta

One of the most painful things to witness in the tech industry is the constant misinterpretation, or even distortion, of Agile or Lean concepts, and Minimum Viable Product (MVP) is a blatant example.

Eric Ries described it as “[the] version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”. Notice that the description starts with its purpose – however this is commonly disregarded by product makers who just focus on the effort aspect. The concept, which reflects a more than reasonable concern with waste, is used to justify poor design decisions, insufficient resource allocation and an overall lack of vision and strategy. 

Context is key: from Ries’ description, it seems that this is a strategy to validate market fit, and I would argue that it is particularly useful when there is a high degree of innovation involved. Nevertheless I’ve seen it being used countless times to describe long standing backlog items – often in supposedly mature products – that aim to solve validated customer needs.

“Let’s just make an MVP” normally means “we have loads of stuff to do and we can’t prioritize properly or negotiate commitments, so let’s just make a poor man’s version of this solution”. User experience is the first victim – it just needs to work, it doesn’t matter if you need 10 consultants just to plug it in, or if customers are constantly raising support tickets because they don’t know how to operate it. Reliability is second – not to mention security.

Where is the viability in this? 

Imagine if the folks in the Toyota factory back in the 40s did the same – to save time, they would start shipping cars that were unreliable, unsafe, and that no one knew how to drive. Would this be considered a major success in efficiency? Or would it hurt their credibility to death?

Trapped in a chamber: sprint review vs reality

Posted on by spereira.marta

Nothing beats the feeling of presenting a brand new, beautiful and functional user interface for the first time – except for the realization that there is no plan to actually make it available for real users.

Tech companies adopted Scrum as a way to deliver on the Agile promise of fast, incremental value. There is a clear product goal that everyone in the team strives to accomplish during the designated sprint time. When working software is delivered frequently, everyone is happy. The sprint review is a success story, progress is praised, people engage in self-congratulating behavior that keeps morale high. It feels like being in a cozy room with padded walls covered in golden glitter – we did it folks, it works! 

But who is paying for the golden walls? The first sentence of the Agile manifesto contains the answer – our highest priority is to satisfy the customer. However, on many occasions, our beautiful working software is not actually available to those who can take advantage of it for purposes other than self-gratification, for multiple reasons:

  • It’s shielded by a complex provisioning layer that requires the intervention of professional services teams
  • It lacks discoverability, meaning that although users have access to it, they will never find it (unless someone guides them)
  • It replaces another existing product or feature and there is no migration plan
  • It’s not scalable to the point that you can actually roll it out to a user base that is large enough to provide relevant feedback
  • More generally, it lacks 3 out of the 4 marketing Ps – the product works, but there is no price (how does it fit our pricing strategy?), no promotion (how is it going to be communicated?) and no place (how is going to be distributed among consumers – or users)

For some reason, this is rarely a cause of concern for scrum team members – and I am not just referring to product owners (or product managers, considered a broader function), although that sort of attitude is even harder to process when coming from folks in those roles. 

Is it because we think this is always someone else’s responsibility? Are we afraid to break the glass into the outside world, where people (aka customers) are not always super nice and friendly? Do we actually enjoy building products in a vacuum? So many questions, so little time.

Then there comes a time when the golden, padded walls start to crumble. Everyone starts to realize that there is no actual adoption, developers complain to their managers about the lack of transparency and usage data. 

When management decides to shield teams from the brutality of early stage feedback and adoption numbers, they are only buying motivation for the short term. Eventually people will start questioning why the hell are they committing to deliver something within two or three weeks if real users will only be able to get their hands on the prize in half a year or more (assuming things won’t be ditched before they even get to that stage, due to strategy shifts). So let’s be honest, as this is the only way to build trust. And let’s work together to bridge the gap.

A natureza da dor

Posted on by spereira.marta

Depois, disse à mulher:

«Aumentarei os sofrimentos da tua gravidez,

entre dores darás à luz os filhos.

Procurarás apaixonadamente o teu marido,

mas ele te dominará.»

Genesis, 3:16

Passaram vinte dias desde que a Alice nasceu.

A irmã, Inês, nasceu no fatídico mês de março de 2020, quatro dias antes do primeiro decreto de estado de emergência. Nos meses anteriores, nas aulas de preparação para o parto, ouvi vezes muitas vezes que a natureza é perfeita. Talvez por real convicção, talvez como forma de tranquilizar o grupo, a senhora enfermeira tinha como missão encorajar-nos a abraçar o processo da forma mais natural possível. Afinal, nem sempre havia dor, e se havia, ela não era por acaso. Para além disso, o prazer e o amor libertam-nos – e somos nós, as mulheres, quem assume o controlo de toda a química – ocitocina, prostaglandina, adrenalina – a nossa força feminina primitiva aperfeiçoa o cocktail e dispensa qualquer intervenção.

Valeu de pouco esta doutrina, embrulhada numa capa frágil de empoderamento (porque ter poder é, na verdade, poder escolher), à mulher de vinte e nove anos encostada a um canto da sala de recobro, sozinha, em hipotermia, após uma cesariana de emergência. O útero começou a contrair dois dias antes, mas a natureza não foi capaz de produzir muito mais para além da dor. O problema é conhecido – desproporção cefalopélvica – a cabeça de um recém-nascido é, em média, dois centímetros mais larga do que o canal de parto. Escreveu Bill Bryson:

Se alguma vez houve um evento que contraria o conceito de desígnio inteligente, é o ato do parto. Nenhuma mulher, por mais devota que seja, alguma vez disse enquanto dava à luz, “Obrigado, meu Deus, por este processo tão bem pensado.”

Bill Bryson, O Corpo: um guia para ocupantes

Não há, portanto, amor que valha a estes dois centímetros. Ele só chega depois do alívio, e chega com tamanha força que nos turva a memória. Por isso, dois anos e meio depois, entro novamente na sala de parto. A velocidade do processo, desta vez, foi literalmente estonteante. A “hora curta” não deu tempo à anestesia, o que fez com que parecesse um dia. O Prémio Nobel da Literatura vai para quem conseguir descrever a dor – apenas posso falar da vontade de desmaiar, da sensação de fraqueza e de impotência, muito contrária ao vigor feminino quase místico que deveria, supostamente, surgir. E quanto aos dois centímetros, foram resolvidos por um engenho humano um pouco arcaico chamado episiotomia. Mais uma vez, onde estava a perfeição da natureza quando foi precisa?