Pricing Products

I view pricing as a part of the user experience of a product. I think technology has opened the doors towards more pricing options, but it really should tie back to the user experience to determine if the product is priced in the right way.  Pricing should be representative for the value the product provides for the user.

I do feel an ethical responsibility with the products I work on. I don't work on products that serve to extract as much money as possible from the average consumer, including using techniques such as anti patterns and gambling.

Shipping Products

There’s a lot that is involved in getting a product out the door!

Pre Development

Do the work upfront

Do sufficient opportunity discovery to work towards a realistic release of the product. It's important to have ideas that enter the funnel for development to be reasonable, vetted and valuable. The work done during the opportunity stage not only gets ideas to development, but should be the same ideas that get through development, changing and altering slightly based on improved thinking during the development process.

Start with a Release Checklist

Release Checklist

Part of onboarding at a new company involves developing a release checklist to guide the success of new major features (and minor features) from day 1. This, along with the Living Documentation, will inform what documentation outputs are needed for any kind of feature launch of any size.

Development in Progress

Living Documentation

Documentation is definitely something that is great in theory and very hard in practice. Here are my principles when it comes to documentation:

• Have a centralized documentation system - Confluence, Coda, Notion, etc. Something that is searchable.
  • Google Docs don't work well. It's easy to create documents but the editing can get out of control a bit.
• Start as early as possible. If there's a PRD, Story Map or PRFAQ/Working Backwards doc, use it to make the basis of the living documentation
  • During development, capture all the business logic details as the team works through the stories.
  • Before release, compare the current documentation with what the needs of sales, account management/implementations and support have with the new feature.
  • During go-live and rollout, continue to document any differences in behavior or perception as the feature is live - focus on answering frequently-asked questions during this time.
    • For B2B features, also do this practice when rolling out to second and third customers.
  • If development works on a bug or story in the same area of the feature, make sure it's included in the story to update proper documentation.
  • Review documentation on a yearly basis to ensure it's still accurate.

<aside> ✨

Living Documentation is one of the things that I think can be made more efficient through working with an LLM to help keep track of what needs to be updated with released code.

</aside>

Logical check-in points with stakeholders

Depending on the size of the feature or initiative, it's worth deciding up front where and how to check in with stakeholders during the course of this product development. Some examples: