Hacker News Reader

Comment by nicoslepicos | Hacker News Reader

Agree. Conceptual Debt is the domain of Product Managers, and they're the ones responsible for preventing it and fixing it.

View on HN

This is absolutely wrong in practice, in my experience. Non trivial conceptual issues are very often raised when trying to implement things. Only then do you start to realize you're starting to code the same thing twice, or that you've got many unhandled behaviors, etc.

Bad conceptual design is due to poor communication between end-users,product owners, and coders.

The reason a product owner can't handle all conceptual issues in advance is because he speaks english, and not logic. His terms are poorly defined compared to the need of a mathematicaly correct definition of his problem space. Only when you start to code things do you realize that things are much more complicated ( or can be simplified).

The reason a product owner can't handle all conceptual issues in advance is because he speaks english, and not logic

Is there a reason the product owner can't speak both english and logic? It seems like establishing mental models of how the application is working requires at least some level of logical thinking.

In the past I have worked on projects where the product owner wasn't thinking only in terms of output and not how the application achieved its goals. The result was an initial overly simplistic happy path design, followed by developers poking holes in it, followed by the product owner adding a series of exceptions to the design to try to handle the edge cases. Neither side felt ownership of the mental model, and it turned out to be a mess.

"Is there a reason the product owner can't speak both english and logic?"

Theoretically no, but it's a big ask for one person. In reply to this entire chain, I'd suggest that it's actually something for the technical lead and the Product Manager to work out in conjunction with each other. For any team past about 4 people, it's just going to be too much to expect someone to both be the technical lead and be in contact with the users enough to be able to make those decisions. (A bit of crosstraining may be good, but trying to avoid that specialization is probably asking for trouble.)

If the PM and the lead don't respect each other enough to make that work, you've got a people problem. There's a lot of people-problem ways to muck this up, unfortunately. (Most obviously, I'd contend that making the PM be above the tech lead is a very common failure case. If you can't trust anyone on the engineering team to have a roughly equal voice in the product design process... uhhh... that's a pretty big problem on its own!)

By speaking logic, i meant using a rigourous formalism to express processes and behaviors. Things like state diagrams, or code.

But many specifications today are written in terms of user scenarios, or general definition, in english. A coder would fall in the same trap should he use the same formalism, only he would probably feel the need to specify its problem using rigourous design tools.

Oh god, the happy path fallacy. I've seen this too many times. Product manager comes up with conceptual model X, once implementation starts people it's brought to attention that X will only work under condition A,B,C, which together only occur for 5% of the users. Instead of reverting X, and trying out Y instead, the heavy train to finish X has already gained momentum and exceptions are added into the UI breaking the whole flow required for X to be intuitive.

The sad part is that these unreasonable conditions are usually quite obvious to spot early on. I'm just making things up now but it can easily be things like requiring the user to hand over their bank log in details so that random startup can analyze their expenses, analytics that require write access to some big corporations sql database or that every user in the whole world uses Outlook 2007 and are willing to install our plugin.

Reply on news.ycombinator.com