Are you sick and tired of rushing all your work due to stakeholder pressure? Perhaps the “Product development triangle” below will help! Next time you are pressured, put this out and assess what can be cut:
• Features — Users will get poor, limited functionality that will compromise their experience and might present a poor version of what was initially intended.
• Edge Cases — The product might work fine for 95% of people, but disappoint the remaining 5. Can you afford the bad reviews coming from those users?
• Testing — Testing, especially integration tests extends the development cycle. Are you ready to risk bugs and unintended issues going to the users?
• UX delight — Putting any wireframe that devs can work with can be fast. However, if this UX is then to be consulted with different experts, and shown to users as part of the discovery process, it will take time
• Copy — Good copy can elevate the product, bad copy can break it. You can go with what the designer or you thought about, but you can make it a discussion. Bonus complexity points, if you wish to polish the copy in all languages your product is available in.
• Consistency — Making sure the UX of the new update fits into the product is an additional level of polish. Especially, if your product didn’t invest in a design bible or similar document.
• Scalability — Did you check if the update will work for 100,1000, or 1000000 users? Or is the fact it works for a single tester acce[table ;-)?
• Integration — Is the code designed in a way to fits well into the code base and reuses components? Or are you willing to skip this phase and just ask the team to code it?
• Ease off updates — Will this be a one-and-done work? Or do you plan to iterate on it? Can you afford more dev time to make the updates possible later down the line?
DON’T GET ME WRONG: 𝗥𝗘𝗟𝗘𝗔𝗦𝗘𝗗 𝗜𝗦 𝗕𝗘𝗧𝗧𝗘𝗥 𝗧𝗛𝗔𝗡 𝗣𝗘𝗥𝗙𝗘𝗖𝗧!
This post is not about mockery. It’s about being able to make a choice on where can you compromise and…